The review of the connection-check fix found the second-order race it
opened: _apply_equipped_card sets _CARD_CONNECTED = True and bumps
card_session *before* it clears and reads the ICCID (and long before the
network state / TERMINAL PROFILE / drain finish). A worker poll landing
in that window saw connected + a fresh session + iccid = None and
consumed the card with a bogus 'no ICCID' skip - the card was never
installed. The `equipping` flag could not guard it either: the manual
/api/command equip path never sets it.
The fix marks the finished init instead of guessing:
- _apply_equipped_card sets `server.card_ready_session =
server.card_session` as its last statement;
- the startup init (which inlines the post-equip work and never runs
_apply_equipped_card) sets the same marker;
- the worker requires the marker to match the card session, so it acts
only on a fully initialized card - a genuinely unreadable ICCID still
acts and reports its skip, as designed.
Tests: a worker test that keeps the marker stale for a couple of polls
(no attempt - verified to fail without the guard), the marker pins for
both equip paths, and the fake server carries the marker (a real
attribute) instead of inventing state. The unused `server` parameter of
_ram_batch_start is gone, and the two comments that called this work a
"review" now say audit.
915 frontend + 924 Python; sw cache simple-v438 (unchanged).
catarrh
262041795c