perf: ESP32 cold-build stalls mid-framework-lib compile (no active compilers) #117

Summary

First cold fbuild build tests/platform/esp32s3 -e esp32s3 (and the same pattern on tests/platform/esp32dev) consistently stalls after ~13–15 minutes of genuine compile activity into an indefinite hang. While hung:

• tasklist shows no xtensa-*-elf-gcc, clang, ld, or similar compiler processes.
• Only the fbuild-daemon + fbuild.exe CLI remain.
• ~/.fbuild/prod/daemon/daemon.log keeps emitting "Daemon staying alive: build/deploy operation in progress" every minute.
• .fbuild/build/<env>/release/ is frozen at ~9.5 MB of framework library .a files but never advances to linking or firmware.bin / firmware.elf.
• The daemon remains responsive to fbuild daemon status.

Killing the CLI (or the daemon) unblocks the pipeline; the next build resumes from the cache.

Environment

• Windows 10 Pro x86_64
• Release fbuild.exe / fbuild-daemon.exe from main (8858dda)
• ESP32-S3 DevKitC-1 on COM13 (303a:1001)
• FBUILD_PERF_LOG=1 FBUILD_USE_ESPFLASH_VERIFY=1 FBUILD_USE_ESPFLASH_WRITE=1 in the daemon env

Repro

1. rm -rf tests/platform/esp32s3/.fbuild
2. FBUILD_SELF_EVICTION_SECS=3600 ./target/.../fbuild-daemon.exe --port 8765 &
3. ./target/.../fbuild.exe deploy tests/platform/esp32s3 -e esp32s3 --port COM13 -v

Observed: ~15+ min in, framework library compile phase is done, no compile / link processes run, build never advances.

Why this matters

Blocks end-to-end hardware benchmarking for the warm-deploy loop (#114) — I couldn't measure the trust-skip (#116) delta on real hardware because the cold bring-up never completes.

Next steps

• Add wall-clock + last-phase tracing to the orchestrator tail after per-library compile so a future hang surfaces the specific phase.
• Audit the post-library-compile handoff in fbuild-build::esp32::orchestrator for a missing join / deadlock on the library compile task pool.
• Check whether the stall correlates with library_compiler emitting the last compile [matter]: ... lines — the Matter library may be pulled in as an unexpected lib_deps dependency and the compile pool may be exhausting worker slots.

Related: #91 (warm-build instrumentation), #114 (warm-deploy loop), #116 (session-trusted verify-skip).