stk: never shadow a paused command with a new menu selection

The stuck-card pattern: after a Back TR the card re-issues the parent menu
as a new SELECT ITEM (91XX -> FETCH, paused, awaiting TR), but the UI's
back/timeout branch ignored that response and showed the cached top menu;
the next item click then sent ENVELOPE(Menu Selection) while the card was
waiting for the TR. The card answers such an ENVELOPE with 9000 (not the
usual 91XX), and menu-select cleared the pending command without a TR,
leaving an unfinished proactive session until reset/equip.

- server: _finish_pending_menu() answers a paused command with a cancel TR
  (0x10) before /api/menu-select sends its ENVELOPE and drains a 91XX
  follow-up, so a new selection can never shadow an unanswered FETCH
- frontend: stkMenuRespond('back'|'timeout') renders the follow-up command
  from the server response (SELECT ITEM / DISPLAY TEXT) and shows the
  cached top menu only when the TR answer carries no command (9000)
- tests: finish-pending cancel TR + chain drain (Python); stkMenuRespond
  back/timeout/cancel/ok rendering (frontend); help/AGENTS updated;
  SW cache v107 -> v108.

frontend/index.html

@@ -5486,9 +5486,13 @@ async function stkMenuRespond(result) {
 	try {
 		const data = await pysimFetch('/api/menu-respond', { result: result });
 		if (result === 'cancel' || result === 'back' || result === 'timeout') {
-			stkMenuRenderItems();
-			document.getElementById('stk-menu-buttons').classList.add('hidden');
-			document.getElementById('stk-back-btn').style.display = 'none';
+			if (data && (data.type === 'select_item' || data.type === 'display_text')) {
+				stkMenuHandleResponse(data);
+			} else {
+				stkMenuRenderItems();
+				document.getElementById('stk-menu-buttons').classList.add('hidden');
+				document.getElementById('stk-back-btn').style.display = 'none';
+			}
 			return;
 		}
 		stkMenuHandleResponse(data);