test runner: add the stuck-card watchdog

A card that stops answering (no SW, no driver error) leaves the runner
inside a blocking SCardTransmit while it holds the card lock - Stop
cannot take effect, the presence monitor waits for the lock and a load
test hangs in that iteration without explanation.

The runner now beats a progress heartbeat (each step start/finish and
each attempt of a bounded STATUS/drain loop); after _TEST_STEP_TIMEOUT
(30 s) the watchdog flags the run `stuck`, records the step and the idle
time, sets the stop flag and tries to cancel the blocked transmit by
disconnecting the PC/SC link on a daemon thread.  The disconnect must
run in the background: pcsc-lite serializes it behind the pending
transmit (both take the per-context lock), so a synchronous call would
block the watchdog instead of cancelling anything.  Where a platform
does cancel, the step fails through the ordinary on_fail path; either
way the finalisers map `stuck` to `error` - a stuck card is not a user
stop - and the pending drain is skipped on the dead link.  The
transport is marked stale once the disconnect returns, so the next equip
rebuilds it.

The run status gains `stuck` and `heartbeat`.  Help EN/RU,
docs/test-scripts.md, docs/api.md, the CHANGELOG (folded into the
unreleased 3.37.0) and both AGENTS describe the behaviour and the
background-disconnect caveat; the sw cache is simple-v476 (help is
precached).

Tests: tests/test_test_watchdog.py (17: the check rule, the abort, the
final status of the single/load/suite runs and a blocked-runner
integration case).  1058 Python + 1069 frontend.

docs/api.md

@@ -1039,7 +1039,15 @@ The current (or last) run:
 ```
 
 `status` becomes `ok`/`warning`/`error`/`stopped` when the run finishes;
-expected/actual pairs are reported per check.
+expected/actual pairs are reported per check.  A card that stops answering is
+not waited on silently: after 30 s without runner progress the watchdog sets
+`stuck: true`, `stop` and `error` (`the card stopped responding (step N, no
+answer for N s)`) and tries to cancel the blocked transmit by disconnecting
+the PC/SC link on a background thread (pcsc-lite serializes the disconnect
+behind the pending transmit, so the call returns only when the driver's card
+timeout fires).  Once the step returns, the run finalises as `error` - a stuck
+card is a failure, not a user stop - and the next equip rebuilds the link
+(the transport is marked stale).
 
 ### `POST /api/test/stop`