Apply PlatformIO build_unflags to the effective native flag scopes

[zackees]

Parent: #34

Problem

build_unflags is more than user-flag cleanup. PlatformIO applies it against the effective SCons environment after board flags, user flags, framework scripts, and other mutations have contributed to the final flag scopes.

PlatformIO source evidence

• ProcessProgramDeps() applies board extra flags, then BUILD_FLAGS, then framework scripts, then ConfigureDebugTarget(), and only after that calls ProcessUnFlags(BUILD_UNFLAGS): .cache/platformio-core/platformio/builder/tools/piobuild.py:94-128
• ProcessUnFlags() removes matching entries across parsed flag scopes, including ASPPFLAGS: .cache/platformio-core/platformio/builder/tools/piobuild.py:256-266
• PlatformIO has a regression test where build_unflags removes values injected by an extra_scripts SCons mutation, not just values typed directly in build_flags: .cache/platformio-core/tests/commands/test_run.py:143-197

Current fbuild state

• PLATFORMIO_BUILD_UNFLAGS is recognized as supported and has an accessor: crates/fbuild-config/src/pio_env.rs:15-21, crates/fbuild-config/src/pio_env.rs:111-121
• I could not find any code path where those unflags are applied to the effective native flag set
• fbuild currently merges user flags by appending/replacing some flag classes, e.g. ESP32 apply_user_flags(): crates/fbuild-build/src/esp32/orchestrator.rs:1257-1276

Requested change

Implement build_unflags in native mode against the final effective flag scopes that fbuild assembles, not only against raw user-provided build_flags.

Questions to resolve

• Which scopes should be covered in fbuild (compile, link, assembler, include paths, libs)?
• Should support be exact-match only, or also special-case macro/key semantics as fbuild already does for -D replacement?
• How should this interact with platform-specific orchestrators that currently assemble flags differently?

Acceptance criteria

• build_unflags affects the effective native build result
• Removal is applied after board/framework/profile/user contributions are combined
• Tests cover at least one removal from each supported scope
• If any PlatformIO build_unflags behavior is intentionally out of scope, the limitation is documented and diagnosed clearly

[zackees]

Resolved across all platforms.

• PR feat(build): apply build_unflags to framework compile flags, ESP32 wired (#37) #63 introduced the trait-level mechanism: new `Compiler::build_unflags()` method with default `&[]`, default `compile_c`/`compile_cpp` impls filter both platform and user flags through `pipeline::remove_unflagged_tokens` when non-empty, and `BuildContext` gained a `build_unflags` field. ESP32 was wired as the reference implementation.

• PR feat(build): wire build_unflags through all remaining platform compilers (#37) #64 wired the same pattern through every other platform: AVR, Teensy, generic ARM (STM32 / RP2040 / Apollo3), nRF52, Renesas, Silabs, CH32V, SAM, and ESP8266.

Scope covered:

• Compile flags (C, C++): framework + toolchain + user — filtered in the default `compile_c` / `compile_cpp`
• Link flags: already filtered in `BuildContext::new` via `remove_unflagged_tokens(&mut overlay_link_flags, ...)`
• Assembler / include paths / libs: the shared `remove_unflagged_tokens` helper is now `pub`, so any future caller that wants to apply unflags to those scopes can do so with the same PlatformIO-compatible semantics.

Tests cover trait default returning empty, configured unflags round-tripping through the trait method, and end-to-end stripping of a framework-contributed `-std=gnu++2b`.

Closing.