fix(monitor): fbuild monitor never streams serial lines; bare invocation returns immediately; default port is /dev/ttyUSB0 on Windows

[zackees]

Severity: CRITICAL for the bench loop (not CH32V-specific) — fbuild monitor cannot show live serial output at all, and a bare invocation returns instantly. On bench day the "flash manually, then watch serial" recipe has no working monitor leg in the CLI.

Problem

Three compounding defects in the standalone monitor path:

1. Bare fbuild monitor -p COM5 returns immediately. POST /api/monitor only runs a monitor loop when halt_on_error/halt_on_success/expect/timeout is set (has_conditions, crates/fbuild-daemon/src/handlers/operations/monitor.rs:292-295). Without a condition it opens the port in the daemon and returns "monitoring COMx at 115200 baud" — then nothing.
2. Even with --timeout, no serial line ever reaches the terminal. Each line is emitted daemon-side via tracing::info! (monitor.rs:107-109). The CLI's client.monitor() is a plain JSON POST (post_operation, crates/fbuild-cli/src/daemon_client.rs:603-625); fbuild-cli contains zero WebSocket/NDJSON monitor code (verified by grep). The user sees one summary line after the timeout.
3. Default port is /dev/ttyUSB0 (monitor.rs:254) — guaranteed open-failure on Windows when -p is omitted, instead of picking a detected port.

What works today (bench workarounds, verified)

• fbuild serial probe read --port COMx --baud 115200 --seconds N — in-process, prints raw bytes live (serial_probe.rs:218-258).
• Python fbuild.api.SerialMonitor (WebSocket /ws/serial-monitor — the FastLED contract path).
• --expect / --halt-on-success patterns for pass/fail-only checks.

Fix direction

Make /api/monitor stream NDJSON the way /api/build already does (build_streaming, daemon_client.rs:283-372 has the client-side pattern to copy); default a sensible timeout; default the port from live enumeration instead of the hardcoded /dev/ttyUSB0.

Acceptance

• fbuild monitor -p COMx prints incoming serial lines live until Ctrl-C/timeout.
• Omitting -p on a machine with one detected serial port monitors that port; with zero ports it errors with a port list, never /dev/ttyUSB0.
• Existing --expect/halt behavior and the WS /ws/serial-monitor contract are unchanged.

Found during the 2026-07-21 CH32V bench-readiness sweep (deploy/serial audit pass).

[zackees]

Parent meta: #1130 (2026-07-21 CH32V bench-readiness sweep).