qemu_cortex_m0 integration fixtures flake under full-suite load

[JPHutchins]

Warning

LLM Disclosure

This issue was filed by claude-opus-5[1m] on behalf of @JPHutchins, who asked that the findings from the smpclient screaming-goblin kickoff session be recorded as issues for durable context. Observed while validating #128 and explicitly ruled out as being caused by it.

The qemu_cortex_m0 integration fixtures intermittently fail their ready probe or time out mid-transaction, but only when the full suite runs — not in isolation. Seen on both:

• test_noparams_falls_back_to_defaults[qemu_cortex_m0.serial] (local full-suite run)
• test_max_payload_roundtrip[qemu_cortex_m0.serial_buf256] (CI, run 32543679115)

Each presents as repeated Timeout (1.0s) waiting for request ... EchoWrite(d='smpclient-integration-ready') until the fixture gives up.

Why it is not #128

Measured directly, 15 runs each in isolation — the fixture is clean either way, so the failure needs full-suite conditions to appear:

Tree	Result
with #128's pacing	15/15 pass
main (no pacing)	15/15 pass

Two consecutive full-suite runs with the final #128 change were also clean (229 passed / 101 skipped / 0 failures), so this is infrequent.

Likely cause

qemu_cortex_m0 is the most resource-constrained fixture in the registry — 16 KB of RAM — and ServerFixture.max_reliable_line_packets already caps it at 3 line packets with the note that it "hangs on transactions beyond ~three line packets". Under full-suite load (many concurrent qemu instances competing for host CPU) it appears to miss its 1.0 s ready-probe window.

If that is the whole story, the fix is likely a more generous ready-probe budget for emulated fixtures rather than anything in the transport — but it should be confirmed rather than assumed, ideally by capturing a failing run's log the way #128 did.