fix: BER-safe proactive TLV walks + hardened FETCH loop (v3.6.57)

The live 500 in the Explore ('OTA send error: index out of range') was a
parser bug, reproduced with the live FETCH shape: _parse_proactive_header
walked the command TLVs reading the length as a single byte, so the card's
SEND SHORT MESSAGE with its 150-byte SMS TPDU (8B 81 96) was mis-walked
into the TPDU and eventually indexed past the end (val[2] on a short
slice) - the FETCH was left unanswered and the request answered 500.

- _ber_tlv_list/_proactive_body helpers: BER lengths (_ber_len_at) plus a
  bounds check that stops at a truncated TLV instead of walking into the
  value; _parse_proactive_header, _parse_display_text, _parse_select_item,
  _parse_setup_menu_items, _tlv_map and _decode_poll_negotiation all use
  them now (the same latent bug for any long-form TLV);
- _run_proactive_chain guards every step (header parse, proactive log,
  on_fetch, BIP/timer handlers): an exception is logged with the offending
  FETCH bytes and the TERMINAL RESPONSE is still sent - a decoder bug can
  never leave a FETCH unanswered again;
- the expanded-registry report distinguishes a request error from a remote
  SW: 'ELFs: request error (index out of range) - compact listing used'.

Regression tests: the live long-form FETCH shape parses (header + TLV map +
TPDU), truncated TLVs stop the walk, and a raising parser still gets a TR.

sw cache simple-v330; tests: 553 Python / 711 Node.

frontend/sw.js

@@ -1,4 +1,4 @@
-const CACHE = 'simple-v329';
+const CACHE = 'simple-v330';
 const URLS = [
   'index.html',
   'help.html',