ESP32: local framework archives ignore changed compiler flags #1863

Switching an ESP32 project from LTO to no-LTO reuses the previous build's framework library archives, even though sketch and project library objects rebuild with the new flags. The resulting link fails with plugin needed to handle lto object followed by undefined FS/LittleFS symbols.

Observed while validating FastLED/FastLED#4994 on ESP32-C6 with fbuild 2.5.49, Arduino 3.3.5, ESP-IDF 5.5.1 and GCC 14.2. The first build used -flto=auto; the next used -fno-lto. Both compile and linker flags were set explicitly. The second build retained fw_libs/libfs.a and liblittlefs.a with first-build timestamps. FS_a42b.o has empty .text and .gnu.lto_* sections. A supported project --clean bypasses the stale local outputs.

Root cause: FwLibsPlan::new in crates/fbuild-build-esp/src/esp32/orchestrator/framework_libs.rs treats any existing local archive as a cache hit. The global FrameworkLibraryCache includes effective compilation flags and framework contents in its key, but hydrate skips existing destinations. No local identity proves those destinations belong to the active key.

Plan:

• Add failing filesystem regressions for a flag-change build and legacy local archives without an identity.
• Validate local archive identity against the existing content-addressed global cache key before hydrate/reuse; discard incompatible local archives and rebuild or hydrate the matching ones.
• Preserve warm reuse for matching identities, clean-only behavior, and normal global cache sharing.
• Run the framework-library/cache tests, formatting and lint. Confirm switching LTO modes cannot silently reuse the other mode's archives.