v3.25.3: the card's BIP commands during test runs

The runner's three FETCH/TR sites (the proactive-drain action, the
expectation, the cleanup drain) built every TERMINAL RESPONSE from the
script, so a card-announced OPEN CHANNEL during a run was answered
"performed successfully" without opening a channel - SEND DATA was
dropped and RECEIVE DATA returned nothing (silent data loss, broken
applet state).

_test_step_tr now routes 0x40-0x44 through _handle_bip_command: the
terminal answers for real, so the card's channels work inside a run.
The script keeps an escape hatch - a respond with `raw` TLVs or a
non-ok result wins (the applet error-path tests).

The BIP events flow during a run again for the channels the card
itself opened: _bip_data_available and _bip_flush_channel_events no
longer stop at the run guard (a channel only exists because the card
opened it) and the runner flushes the link events after each TR, so an
applet's own HTTP/BIP conversation completes inside a scripted run.
BIP control stays blocked (409).

Tests: the drain/expect/cleanup routing, the raw and non-ok-result
overrides, the run-time data-available and link events.  883 frontend
+ 873 Python; sw cache simple-v427.

docs/test-scripts.md

@@ -525,6 +525,29 @@ The `proactive-drain` action's `respond`/`first` use the same shape (the command
 type varies per drained command, so `text`/`item_id` apply where the command
 carries them).
 
+### BIP commands in scripts
+
+The card's own BIP commands (`OPEN CHANNEL` 0x40, `CLOSE CHANNEL` 0x41,
+`RECEIVE DATA` 0x42, `SEND DATA` 0x43, `GET CHANNEL STATUS` 0x44) are answered
+by the **terminal**, not by the script: during a run the channels really open,
+the data really flows to/from the configured BIP target, and the BIP events
+(Data available, Channel status) flow for the channels the card itself opened -
+so an applet's own HTTP/BIP conversation completes inside a scripted run.  The
+BIP **control** API stays blocked while a run is active (409), like the
+terminal's other automatic actions (polling, timers, menu).
+
+A step's `respond` overrides the terminal when it carries `raw` TLVs or a
+**non-ok result** - the way to script an applet error path:
+
+```json
+{"type": "expect", "command": "OPEN CHANNEL",
+ "respond": {"result": "refused"}}
+```
+
+A plain `{"result": "ok"}` (or no `respond`) leaves the BIP answer to the
+terminal; the step log names it (`BIP: the terminal answered OPEN CHANNEL
+(0x40)`).
+
 ## The two PoR transports (SPI2)
 
 1. **Inline** - the card answers the ENVELOPE `9000` with the PoR in the