rig_https_local / rig_https_bad_finished start the listener before taking the DeviceLock, so a queued run's ACCEPT_TIMEOUT expires #246

Seen during the 2026-09-24 pre-merge hardware runs. A rig_https_local run failed as a fixture problem: it spent 39 min queued for the U64E, and the listener's accept timed out first.

Mechanism. Both rigs start their TLS listener with a wall-clock ACCEPT_TIMEOUT (default 600 s × the turbo scale) before they acquire the DeviceLock. The lock is designed to queue behind a live holder for as long as it takes, so any queue longer than the accept budget fails the run before the C64 ever connects. It looks like a network or rig failure rather than a queue delay.

Workaround used: `ACCEPT_TIMEOUT=10800`.

Fix: take the DeviceLock (and run prepare_device/preflight) first, then start the listener, or start the accept clock only once the lock is held. Pin it with a hardware-free test that fakes a slow acquire.

🤖 Generated with Claude Code