fix: recover the SMS-SUBMIT listings in RAM Explore (v3.6.4)

Explore returned partial data (no ELF/module entries, the installed package
missing) and then failed with cntr_low.  Two causes, both in the
actual-response SMS-SUBMIT path the card uses for big listings:

- `_find_sms_tpdu` read TLV lengths as a single byte; the FETCH carries
  `8B 81 97 ...` (BER long form) for the big pages, so it returned a
  corrupted, truncated TPDU.
- `_calc_ud_offset` treated the SMS-SUBMIT relative validity period (VPF=10)
  as 7 bytes instead of 1, shifting the UD offset: `_parse_sms_concat` then
  read a bogus UDH and reported no concatenation, so the segments never
  assembled and the PoR/data was dropped ("RAM RESPONSE-PACKET: empty").
  The step was marked failed, the counter did not advance, the same counter
  was retried and the card answered `cntr_low`, which also blocked P1=10
  (modules) where the installed package appears.

- the captured segments now always store the assembled UD (`submit_ud_hex`);
  `_sms_submit_por()` rebuilds the DELIVER-style packet (`02 71 00` + UD) for
  `_decode_por`.  Verified against the live capture: por_ok, remote SW 6310,
  438 hex chars of listing data (the exact bytes of the P1=20 page).
- `spPorAccepted` counts `actual_response_sms_submit` (0x0B) as accepted, so
  the counter advances when the data follows via SMS-SUBMIT.

Explore queries follow GP Card Spec v2.3.1 11.4.2.2: compact listings
(P2.b2=0) with the chained GET RESPONSE (`ramGetStatusApdu`, paging P2=00 ->
P2=01), the malformed P2=02 attempt is gone, and the ISD-only query (P1=80)
never pages with next-occurrence (the card shall reject it).

Tests: Python SmsSubmitCaptureTest with the live FETCH bytes (TPDU length,
UD offset, concat reassembly, 027100+UD decode); ram.test.js checks the APDU
builder and the missing P2=02 attempt; cards_counter covers 0x0B.

608 frontend / 492 Python green; version 3.6.4; sw simple-v277.

frontend/tests/ram.test.js

@@ -22,7 +22,7 @@ function extractFunc(src, name) {
 }
 
 // Extract chain builder functions and dependencies
-const FNS = ['berLenStr', 'buildApdu', 'escHtml', 'esc', 'chainInit', 'chainRamBuildRowHex', 'ramFmtLifecycle', 'ramFmtPrivileges', 'ramRenderExploreHtml', 'ramStepLine',
+const FNS = ['berLenStr', 'buildApdu', 'escHtml', 'esc', 'chainInit', 'chainRamBuildRowHex', 'ramFmtLifecycle', 'ramFmtPrivileges', 'ramRenderExploreHtml', 'ramStepLine', 'ramGetStatusApdu',
 	'ramCardIdxAfterRemove', 'ramClearResults', 'ramHideProgress', 'ramOpChanged', 'ramRender', 'ramApplyCard', 'ramExecute',
 	'jcAidNorm', 'jcAidName', 'jcAidSuffix', 'jcAidHtml'];
 let code = '';
@@ -265,6 +265,20 @@ function fakeRamDocument(ids) {
 	return els;
 }
 
+test('ramGetStatusApdu builds the compact chain, never the expanded form', () => {
+	// GP 11.4.2.2: compact listings (P2.b2=0) carry the chained GET RESPONSE
+	assert.strictEqual(ramGetStatusApdu('80', '00'), '80F28000024F0000C0000000');
+	assert.strictEqual(ramGetStatusApdu('20', '01'), '80F22001024F0000C0000000');
+	// the expanded TLV form (P2=02/03) takes no GET RESPONSE and is not built:
+	// its GET STATUS bytes would be `80F2<P1>02 04 4F00 5C.. 00`
+	assert.ok(!ramGetStatusApdu('20', '01').startsWith('80F2200204'),
+		'expanded form must not be generated by this builder');
+	assert.ok(!html.includes("for (const p2Init of ['02', '00'])"),
+		'the P2=02 attempt must be gone');
+	// the ISD-only query is a single occurrence: no next-occurrence paging
+	assert.ok(/if \(p1 === '80'\) break;/.test(html), 'ISD next-occurrence guard missing');
+});
+
 test('ramStepLine shows the PoR verdict and the remote status word', () => {
 	globalThis.t = s => s;
 	globalThis.lookupSw = (a, b) => (a + b === '6700' ? 'Wrong length in Lc' : '');