ci: nightly hardware-attached bring-up CI runner (multi-family)

[zackees]

TL;DR

fbuild's CI today runs on hosted GitHub runners (Ubuntu / Windows / macOS) executing unit tests and building artifacts. There is no nightly job that flashes real hardware and verifies a known-good firmware actually boots, takes serial commands, and round-trips data. Every regression in the deploy/reset/monitor path therefore has to be caught by a human running bash autoresearch locally.

This issue requests a hardware-CI runner with at least one of each supported board family wired in.

Why this matters

The FastLED #3300 / #3325 / #3339 LPC bring-up incident was caused by three independent host-side bugs in ci/util/pyserial_monitor.py, ci/util/port_utils.py, and ci/autoresearch/phases.py that combined to make the LPC845-BRK look silent. Each bug landed in a separate PR over weeks. None was caught by emulator-only CI because there was no real-hardware test. A nightly hardware-CI run would have failed the moment any of the three regressions landed.

Proposed shape

• Self-hosted runner with USB hubs hosting at least one of each supported board family: ESP32-S3, LPC845-BRK, RP2040, Teensy 4.1, STM32 (when supported), SAMD51 (when supported). Pi 5 / NUC is enough hardware.
• Nightly cron job: for each attached board, run fbuild deploy <board> + bash autoresearch <board> against a known-good examples/AutoResearch.ino build at master. Pass = bring-up test (3-way remote_ok/log_ok/echo_ok) returns success. Fail = open a ticket and notify the maintainer.
• Per-PR optional path: PRs touching crates/fbuild-serial/ or crates/fbuild-deploy/ can opt in via label (hw-ci) to run the hardware suite on the PR's head — costs ~10 min of runner time per board.

Acceptance criteria

• One self-hosted runner registered with at least three board families wired.
• .github/workflows/hw-ci.yml with the nightly cron + optional PR trigger.
• Per-board "known-good firmware" pinned in the repo (e.g. tests/hw/known_good_<board>.bin) so the test target is stable.
• On failure, runner posts to the relevant tracker issue with the device output captured.

Out of scope

• Adding hardware coverage for boards not on-hand yet. Track per-family adds separately.
• Pure HIL (hardware-in-the-loop) — this is integration tests, not pin-level simulation.

Refs

• FastLED/fbuild#586 — LPC845-BRK on-hand burn-down meta. Same hardware, different question.
• FastLED/FastLED#3339 — the LPC bring-up incident. Hardware-CI would have caught this six weeks earlier.

Filed from the audit fan-out on FastLED/FastLED#3339.