feat(shrink): make ESP32-S3 printf reduction actually apply

[zackees]

Context

FastLED's ESP32-S3 Blink build with pinned fbuild 2.5.26 still links _vfprintf_r (11,413 B), _svfprintf_r (11,222 B), _dtoa_r (3,223 B), and two get_arg$isra$0 bodies (1,231 B each): 28,320 B before the rest of stdio. The build prints no shrink decision.

The --shrink CLI introduced under #493 exists, but current crates/fbuild-build-engine/src/shrink/resolver.rs resolves Auto to Off for every context, and registry.rs::registry_for returns &[] for every platform. record.rs explicitly says its telemetry is not yet wired into build info. Thus #493's CLI scaffold is present while its promised ESP32-S3 printf reducer is not active. There is no open ESP32-S3 implementation issue from the duplicate search.

Proposal

Finish one measured ESP32-S3/newlib implementation behind the existing shrink flag. Start with explicit --shrink=printf so the linker strategy and formatting behavior can be compared against --no-shrink; use the existing #493 design work where valid. Resolve Auto to Safe only after output compatibility and framework/version guards are demonstrated. Report the resolved mode and applied reducer in build info and build output.

Acceptance criteria

• RED: a focused resolver/link test demonstrates that the current ESP32-S3 Auto decision is Off, and a stock Blink ELF retains _vfprintf_r and _svfprintf_r.
• GREEN: an explicit --shrink=printf Blink build demonstrably replaces those full newlib bodies and records the chosen strategy; a matched --no-shrink build remains the control.
• A same-toolchain Blink A/B report gives both symbol and whole-firmware flash/RAM deltas. The implementation lands only if net flash decreases.
• Formatting tests cover integers, floats, long long values, width/precision, error/errno behavior, and the supported printf entry points. Any semantic differences are documented; Auto remains off until its compatibility policy is justified by those tests.
• Build-info telemetry and the terminal decision agree, and the reducer fails safely or no-ops on picolibc/unsupported toolchains.

Decisions

• P2: this targets a measured 28.3 KB linked cluster, but exact savings require an implemented A/B build.
• File in fbuild because the resolver, link strategy, and build-info emitter live there; FastLED can consume the released behavior afterward.
• Scope the first implementation to ESP32-S3 Xtensa plus newlib; do not assume all platforms share its libc or printf semantics.

Related issues

• fbuild build: --shrink[=MODE] (default auto) for per-platform flash reduction via spec-file printf swap #493 describes the intended shrink design and was closed after the CLI scaffold shipped. This is the unimplemented ESP32-S3 linker/reducer follow-up, not a second CLI proposal.