audit: blocking operations with no timeout (meta) #802

Meta tracking issue. Sub-agents will post per-area audit reports
as sub-issues. Goal: surface every blocking operation in fbuild
that can hang indefinitely without a bounded timeout, so they can
be triaged and fixed.

What counts as a "blocking operation with no timeout"

• subprocess calls without an --timeout-style limit:
  • std::process::Command::output() / wait() (waits forever on a stuck child)
  • tokio::process::Command::wait() without tokio::time::timeout
• network I/O without a deadline:
  • reqwest::blocking::get(...) without .timeout(...)
  • reqwest::Client::default() (no per-connection timeout)
  • TcpStream::connect(...) without connect_timeout(...)
  • HTTP downloads that read indefinitely from a slow producer
• locks / channels:
  • Mutex::lock() / RwLock::read() without timeout (no try_lock_for)
  • mpsc::Receiver::recv() without recv_timeout
  • file-based advisory locks acquired in a busy-loop without a wall clock
• thread sleep / busy-poll loops without an outer deadline
• async .await on long-lived futures (channels, IPC, daemon comms) not
  wrapped in tokio::time::timeout
• shell scripts in ci/ invoking curl / git / gh without --max-time

What does NOT count

• a missing timeout on an operation that's already bounded by an outer
  guard (e.g. tokio::time::timeout(deadline, ...) wrapping the call)
• Drop impls (those run synchronously by definition; the right fix
  is upstream of the drop)
• short-lived utility code that's only invoked from CLI binaries with
  a process-level timeout already in place

Sub-issue checklist

Each sub-agent files one of these. The checklist below auto-updates
as the sub-issues land.

• fbuild-build (build orchestration, per-platform orchestrators, compile + link)
• fbuild-daemon (HTTP/WS server, handlers, broker, device manager)
• fbuild-serial (serial monitor, USB-CDC retry, deploy preemption)
• fbuild-deploy (esptool / avrdude / picotool / dfu-util / pyocd invocation)
• fbuild-packages (URL downloads, toolchain resolution, library manager, parallel pipeline)
• fbuild-cli / fbuild-python (CLI HTTP-client, PyO3 bindings)
• fbuild-core (subprocess, fingerprint, install-status)
• ci/ scripts + .github/workflows/ (curl / gh / git invocations)

Per-sub-issue report format

Each sub-issue should include:

• a brief intro saying which area was audited
• a table of findings: file:line | description | suggested timeout / fix
• severity per finding (CRITICAL = daemon hang risk, HIGH = build hang, MEDIUM = CLI hang, LOW = ci-only)
• a quick "what was searched / how" so a follow-up auditor can re-check

This issue auto-closes once every sub-issue is closed.