v3.25.7: the ENVELOPE response-bytes fetch

The live report: an SPI2 01 secured packet reported no PoR.  For such a
packet TS 31.115 4.2/4.4 (b6=0) has the Response Packet retrieved by the
ME from the ENVELOPE exchange (SEND SHORT MESSAGE is the b6=1 case), but
_send_envelope only asked for response bytes after a 61xx answer - the
card signals them with 62xx/63xx instead (the "more data" quirk the
remote-command SWs already acknowledge, _ram_remote_sw_ok), so the whole
PoR stayed on the card and the late-PoR STATUS poll found nothing.

_envelope_get_response (shared with _send_event_download, which had the
same 61xx-only code): a 61xx names the GET RESPONSE length; a 62xx/63xx
without data gets Le 256 (00c0000000 - a bare 61 no longer emits the
odd-length '%02x' % 0x100 APDU).  The result is adopted when bytes were
delivered (or for a 61xx); otherwise the warning stays, so the v3.6.58
SEND-SM PoR path (the STATUS poll) keeps working.

Tests: the 61xx length, the 63xx+PoR fetch (Le 256), the bare-61
encoding, the warning-kept path (the poll still runs) and the
event-download sharing.  887 frontend + 880 Python; sw cache simple-v431.

frontend/index.html

@@ -1906,7 +1906,7 @@
 // ===== Version =====
 // Single source of truth for the PWA version: shown in the header and used
 // by the server version check in pysimConnect().
-const SIMPLE_VERSION = '3.25.6';
+const SIMPLE_VERSION = '3.25.7';
 document.getElementById('app-version').textContent = 'v' + SIMPLE_VERSION;
 
 // ===== view history (the browser Back/Forward buttons) =====