fix: SDK flags, archive linkage, and Windows esptool provisioning #1677

Context

Full board validation of FastLED/FastLED#4831 with published fbuild 2.5.40 exposed two SDK integration defects:

• RP2040, RP2350, and XRP fail in the real Pico SDK SDFS.cpp: std::make_shared<FsFile>(fd) cannot access the private copy constructor. SDK 5.7.0 supplies build.sdfatdefines in platform.txt, including FILE_COPY_CONSTRUCTOR_SELECT=FILE_COPY_CONSTRUCTOR_PUBLIC; fbuild currently misses these defaults. Real SDK compilation reproduces this for both RP families.
• Teensy framework discovery selects optional SD objects conservatively, then links them directly with mandatory core objects. An unused SDK SD constructor consequently survives. A real Teensy 4.1 Blink build measures 73,728 bytes against the existing 50,176-byte limit, and its map loads SD_c5c2.cpp.o. Hosted Teensy 4.0 and LC also fail size checks.

Evidence: RP2040 failure, Teensy 4.1 failure. These block the downstream ESP AST coverage integration (FastLED/FastLED#4829).

Proposal

Honor Pico platform.txt SdFat defaults with board overrides, using the existing define parsing/expansion path. Include the changed default policy in cache fingerprints before the firmware fast path.

Keep mandatory Teensy and Pico core objects directly linked, but archive selected optional framework libraries using the toolchain's LTO-aware archiver. Link that archive after project objects/libraries so referenced SDK functionality still resolves. Invalidate firmware cached under the old linkage policy.

Acceptance criteria

• RED → GREEN metadata tests for SDK defaults and board overrides, plus actual SDK SDFS.cpp compilation for RP2040 and RP2350.
• A persisted pre-fix firmware cache record misses after the policy change; current records retain warm cache hits.
• RED → GREEN real GCC LTO test: unused optional constructors disappear, referenced SDK members and their dependencies resolve, and mandatory core constructors remain. Run this in an existing CI workflow.
• Actual Teensy and RP2040 builds pass unchanged size limits; an actual SDK consumer still builds and links.
• Workspace lint/tests and platform policy checks pass, followed by published-wheel downstream validation.
• No disabled SD backend, raised size budget, hardcoded downstream SDK workaround, or stale-cache bypass.

Decisions

• Fix fbuild because SDK flag interpretation and framework linking belong to the build backend.
• Keep conservative library discovery; archive extraction determines which optional objects the program needs.
• Preserve existing mandatory core linkage and protect previously fixed SDK consumers.
• Treat cache migration as correctness: successful old artifacts can otherwise hide both fixes.

Related issues

• Teensy 4.x: SPI framework library compiled but not linked — undefined references to SPIClass::* at link time #284 fixed Teensy SDK SPI objects missing from linking; preserve that functionality with archive extraction.
• AVR: framework objects linked directly instead of archived → +10.1% size on attiny85 Blink (Tone.cpp ISR pull-in) #304 addressed analogous unused optional framework object retention on AVR; this issue covers Teensy.

Additional reproduced Pico linkage defect

After applying the SDK SdFat defaults, real RP2040 Blink compilation succeeds but its image measures 172,348 bytes against the unchanged 135,744-byte budget (attributed RAM 9,576 against 9,474). The real map directly loads SDK SD/SDFS objects and retains _GLOBAL__sub_I_SDFS and its .init_array entry. Apply the same optional framework archive mechanism to Pico, preserving mandatory core and support objects, and validate the actual firmware budget before publication.

Additional integration requirements

SDK-only archiving lowers RP2040 to 146,952 image bytes, but the map shows loose FastLED fl.fs.sd+.o still extracts SDFS before section garbage collection. Selected local libraries must also use proper archive extraction on this path. Preserve mandatory core startup objects and verify an unused local SD caller cannot retain an SDK global constructor.

Native Windows now passes the IDF4/IDF5 AST ABI checks, but C6 setup fails because the synthesized tasmota esptool5.1.0 Windows binary URL returns404. That upstream release does not publish Windows binaries. Its actual pioarduino registry descriptor declares the published pioarduino/esptool source archive. Use the supported source/UV installation path for this Windows registry case, preserve the pinned version, and prove actual cold install plus warm recheck in the existing Windows CI workflow.

• RED → GREEN local-library/SDK constructor extraction test and unchanged RP2040 firmware budget.
• RED → GREEN Windows esptool registry URL selection; actual pinned5.1.0 installation and version recheck, preserving legacy3.3 behavior.

Verified resolution

Merged in #1678 as dc87035e2819; published fbuild 2.5.41 comes from validated release candidate b40617fe62. The final lockfile follow-up a7bff04b0937 passed all full CI and review checks.

FastLED/FastLED#4831 pins the actual PyPI wheel. On downstream head 651868a467, all board builds and unchanged size gates passed, including RP2040, RP2350, XRP, Teensy 4.1, its size gate, and OctoWS2811. Windows real SDK provisioning and AST lint also passed.

Local published-wheel image/RAM budgets pass: RP2040 103,328/8,636 bytes; Teensy 4.1 47,104/21,734; ESP32-S3 341,011/40,008. No limits or backends were disabled.