Fix Windows ESP provisioning, Intel macOS wheels, and continued SD dependency discovery #1675

Coordinated consumer failure

FastLED/FastLED#4831 adds required semantic checks against real ESP SDKs. Its hosted matrix exposed three independent fbuild 2.5.39 defects. Fix these in fbuild and publish a validated patch release before updating the consumer pin.

Windows: managed esptool launcher has the wrong filename

Windows required ESP provisioning failure: fbuild attempts to spawn .fbuild-tools/esptool/Scripts/esptool.py.exe version, which does not exist.

source_esptool_path_for_host in crates/fbuild-library/src/library/esptool.rs constructs that path. Installation uses uv tool install; UV 0.8.0 strips the .py suffix from console entry points before adding .exe, yielding esptool.exe. See the pinned UV implementation.

Focused regression library::esptool::tests::windows_source_esptool_resolves_uv_console_launcher creates the actual installed filename in a temporary filesystem and fails against the current locator: missing managed launcher: .../Scripts/esptool.py.exe (0 passed, 1 failed). Correct the locator and retain the existing real version verification. This differs from #1655, which concerns a restored Linux venv's missing interpreter.

Intel macOS: ARM native extension shipped with an Intel wheel tag

Intel required provisioning failure: importing fbuild_runner loads fbuild/_native.abi3.so, but the installed Mach-O is arm64 and the host requires x86_64.

ci/publish.py maps only the ARM macOS artifact into a wheel and tags it for both architectures. The release already builds an Intel artifact. Publish separate accurately tagged Intel and ARM wheels; assemble and install the actual wheel in both existing macOS smoke lanes, verify the installed extension and CLI with lipo, import the extension, and execute the installed CLI. Focused packaging mapping regression failed for both targets before the correction.

RP2040/RP2350: continued preprocessor guard hides SD/SDFS dependency

RP2350 linker failure reports unresolved SDFS after FastLED enables its real SDK SD backend. Related failures: RP2040, XRP controller.

The active header scanner evaluates physical lines instead of continued logical directives. The real guard's trailing && followed by a continued newline is treated as a missing operand, hiding <SD.h> and its transitive SDFS implementation.

Confirmed RED signals:

• scanner::tests::continued_sd_guard_keeps_real_backend_include: zero includes, expected one.
• pico_sd_diag::real_pico_sd_selects_sdfs: actual FastLED source, Arduino-Pico 5.7.0, and compiler defines; cold resolver scans 2,308 files and selects 11 libraries but omits SD/SDFS.
• cache::tests::project_header_edit_reselects_required_library: editing a reached header incorrectly reports a cache hit. This reproduces existing library-selection cache ignores reached headers; --clean does not invalidate it #1607; fix that issue as part of the coordinated change rather than opening a duplicate cache issue.

Implementation and validation plan

• Correct the Windows UV-managed launcher path; retain real executable validation.
• Publish architecture-correct macOS wheels and extend existing release smoke jobs to test installed native bytes.
• Join continued directives while preserving physical include locations.
• Fix library-selection cache ignores reached headers; --clean does not invalidate it #1607 by validating the complete textual dependency closure and ordered library descriptors before accepting cached selection. Review identified two additional regression cases: edits through a continued include, and reversed duplicate-header candidate order. These cases are drafted; their RED runs are still pending.
• Complete focused RED → GREEN tests and scoped lint, independent review, and hosted platform validation. Do not suppress missing SDKs or introduce fake tools/headers.
• Release through the existing exact-candidate-SHA dry run, then publish that same validated SHA. Update FastLED's pin and rerun its required provisioning/matrix.

No complete GREEN or release claim is made yet. The consumer benchmark currently pauses heavy dependent-repository builds; implementation and read-only review continue during that interval.