v3.19.1: the compact-PoR decode guard (applet TAR responses reported as data)

pySim's CompactRemoteResp was applied to every response packet, so a
third-party applet's own TAR response parsed as count=128/SW=0110/data=''
(live 2026-10-04: the alfa-dsa applet's `80 01 10`) - a fabricated status
word and a lost response.

_decode_por now takes the plaintext command script's length (cmd_len): the
compact structure's command count cannot exceed it (TS 102 226 5.1.2
Table 5.1 - each command needs at least one byte), so a larger count is
classified `response_type: 'raw'`, the secured data becomes
`decoded.last_response_data` (a por.data check matches it) and no SW is
decoded; `secured_data` is exposed in every case.

Callers pass cmd_len where they know the plaintext: the test runner's scp80
step (None for a pre-built packet; carried in ctx['last_scp80'] for the
submit-PoR path), /api/send-ota (both paths), the RAM step sender and the
counter probe; a caller without it keeps the previous parse.

Docs: test-scripts.md and api.md describe the raw fallback.
Tests: 821 frontend + 729 Python; sw cache simple-v390.

docs/api.md

@@ -558,6 +558,13 @@ response carries them too, plus an `error`).
 fetched via a proactive command (FETCH). The response contains the
 same `por` structure if decoding succeeds.
 
+When the secured data cannot be the TS 102 226 compact remote response (its
+command count exceeds the command script that was sent - a third-party
+applet's own TAR answers with application bytes), `por.response_type` is
+`raw`, the whole secured data is reported as `decoded.last_response_data`
+and no status word is decoded; `secured_data` carries the response bytes in
+every case.
+
 The SPI2 `por_in_submit` bit (0x20) selects submit-mode PoR.
 
 ### `POST /api/cap-info`