test: hardware validation — capture real traces, calibrate timing (needs-hardware)

[CameronBrooks11]

Validate the modeled contract against a real Marlin controller: capture real serial traces, add to the conformance corpus, tune timing constants (keepalive interval, etc.). Needs physical hardware (next lab session).

See working/mvp-plan.md (M5).

[CameronBrooks11]

Best-effort reset() + connect() landed — here's the hardware-verification checklist

The serial reset and connection handshake are now implemented best-effort, grounded in the Marlin 2.1.x source and printrun/OctoPrint conventions (research notes in working/serial-reset.md). The logic is fully tested hardware-free; the items below are the surfaces that can only be confirmed/tuned on a real winder — please verify each during the next lab session:

• DTR reset actually reboots the board. Confirm SerialTransport.reset() (assert DTR, hold 0.2s, release) makes the controller re-emit start. If it's a native-USB board, DTR is a no-op — confirm connect()'s probe path still works.
• assert_hold (0.2s) is enough for the board to register the reset edge.
• startup_timeout — does start arrive within the per-read window after reset? Bootloader hand-off varies (Optiboot ~0–1s, older Mega up to ~2s). Tune if connect() falls through to probing unnecessarily.
• connect() ready-detection — confirm it returns promptly on a fresh reset (sees start) AND on an already-running board (M110 probe → ok).
• Not flushing the banner — confirm we don't lose the start line on this adapter (we deliberately skip reset_input_buffer()).
• Reset-reason line — expect External Reset for a DTR/edge reset (vs PowerUp).
• Baud — 250000 vs 115200 for the actual controller.
• Bare-open reset — does simply opening the port already reboot the board (driver asserts DTR)? Affects reconnect-without-reset.

Once verified, capture a real session with --log and drop the trace into tests/ (replayable via FakeTransport.from_trace) so each real session hardens the suite.

[CameronBrooks11]

No-12V validation DONE (2026-06-28) on a real RAMPS 1.4 / Marlin bugfix-2.1.x board: connect/DTR-reset, M115 negotiation, reliable framed send, streaming + pause/resume, and M112 e-stop + reset(flush=True) recovery — all green. Captured a conformance corpus (tests/conformance/) via the @pytest.mark.hardware lane, found+fixed the post-kill recovery bug (#21), and confirmed assert_hold=0.2. Remaining (needs 12V): real motion under load, heater/thermal behavior, and timing calibration (keepalive interval, etc.) under power.