v3.17.0: test scripts for the applet handoff - menu by text, spec-order TRs, codings

The applet-testing batch agreed after v3.15/3.16:

- menu-select by text: the step names the item by `text` (+ `mode`
  exact/contains, `case_sensitive`) instead of the install-dependent id
  (both or neither is refused); the runner resolves it against the card's
  cached menu and raises a step error naming the available items when nothing
  (or several items) matches.  The cache is refreshed on every SET UP MENU
  fetch - the proactive chain and the expect step - so an applet install (new
  items/ids after its REFRESH) no longer leaves a stale menu behind.  The
  step editor offers the id or the text + mode and the client-side pre-check
  bounds them.
- TERMINAL RESPONSE object order: both builders emitted the Item identifier
  before the Result (and the scripted builder its Text string before it too);
  TS 102 223 6.8.0 mandates Command details, Device identities, Result,
  Duration, Text string, Item identifier.  `testscript.build_tr` and
  `_menu_send_response` now follow it; `respond.raw` is documented as
  appended after the standard objects, and the exact-byte tests pin the order.
- Text codings: the scripted response codes the GSM default alphabet via the
  GSM 03.38 codec ('00' packed, '04' 8-bit) instead of latin-1, keeps '08'
  UCS2 and sends the spec's null text string for an empty answer; the packing
  helper is shared with the interactive path (`testscript.pack_gsm7`).  A
  UCS2 GET INPUT answer is documented and tested.
- docs/test-scripts.md gained the handoff brief for the applet agent: the
  value-collection table, fill-in worksheets for the two applet scenarios, a
  menu-by-text example, the validation checklist and a format stamp; help
  EN/RU and docs/api.md updated.

Tests: 809 frontend + 705 Python; sw cache simple-v380.

docs/api.md

@@ -667,8 +667,11 @@ keysets, TARs and counters.  The inline `preset` form stays for external
 callers.
 
 **Action steps** (`type: "action"`): `kind` is `envelope` (`event`, `data`),
-`menu-select` (`item_id` 1-255), `file-write` (`path`, `data`, `mode`
-`auto`/`binary`/`record`, `record`), `file-read` (same, verifies `check.data`),
+`menu-select` (`item_id` 1-255, or `text` + `mode` `exact`/`contains` with an
+optional `case_sensitive` - the text is resolved against the card's cached
+SET UP MENU, which is refreshed whenever the card sends the menu), `file-write`
+(`path`, `data`, `mode` `auto`/`binary`/`record`, `record`), `file-read` (same,
+verifies `check.data`),
 `apdu` (raw transport, no auto-handler), `scp80` (`apdu` or `sp`, selected by
 the optional `source` field when both are present; optional `kvn` (keyset
 number 1-15), `tar`/`spi1`/`spi2` overrides - KIc/KID and the counter always
@@ -691,8 +694,10 @@ preceding `scp80` step - PoR-in-submit, SPI2 bit `20`: `status` (the response
 status name, `ok` = `por_ok`), `sw` (the R-APDU status word, exact/mask) and
 `data` (the R-APDU response data, exact/mask)) or `files` (the File List of a
 REFRESH, TS 102 223 8.18; `files` is a list of path hex strings, matched
-order-insensitively); `respond` is the TERMINAL RESPONSE (`result` name or
-value, `item_id`, `text`+`dcs`, raw TLVs).
+order-insensitively); `respond` is the TERMINAL RESPONSE in the TS 102 223
+6.8.0 object order (`result` name or value; `text`+`dcs` for GET INKEY/GET
+INPUT, `dcs` `00` packed / `04` 8-bit / `08` UCS2; `item_id`; extra `raw`
+TLVs appended after the standard objects).
 
 The response is the initial state (`running: true`), the final counter
 (`scp80_counter`) and the step list; poll `/api/test/status`.  The PWA writes