refactor(esp32): migrate linker paths and retire test PathBuf exception

[zackees]

Context

The full Linux Dylint run for fbuild 2.5.29 fails with 19 ban_std_pathbuf errors in the new crates/fbuild-build-esp/src/esp32/esp32_linker_tests.rs split out by #1509. The test module constructs Esp32Linker, whose existing constructor and fields take raw PathBuf; the production implementation in esp32_linker.rs is already on the legacy lint allowlist. Moving tests to a separate file exposed this existing API boundary. The release-gate fix in #1510 needs a documented exception for this test file, then the exception should be retired by migrating the API.

The risk is real: raw paths can differ in spelling on Windows, affecting cache-key behavior (#436, #437, #282). The tests are currently the narrow place where raw values are necessary to exercise the unchanged linker API.

Proposal

1. For the immediate release gate, document and allowlist only esp32_linker_tests.rs under ban_std_pathbuf, leaving production behavior unchanged.
2. Migrate Esp32Linker owned path inputs/fields and dependent call sites to NormalizedPath where possible; retain raw PathBuf only at genuine OS/FFI edges.
3. Remove the temporary test-file allowlist entry when the test constructors can use normalized paths.

Acceptance criteria

• Capture RED evidence: the focused full-Dylint failure on test(esp32): unblock full lint and Windows release gates #1510 at https://github.com/FastLED/fbuild/actions/runs/36301465694, and a focused Windows path-spelling/cache-key regression test that fails with raw spellings.
• Turn those signals GREEN with a migrated linker API and focused Linux/Windows tests; the full Dylint workflow passes on both platforms.
• Delete the test-file ban_std_pathbuf exception and avoid adding a broad exemption.

Decisions

• Priority P1 for the release-gate exception: this currently blocks 2.5.29 publication. The larger API migration can follow after release.
• Scope is the ESP32 linker path boundary, not a workspace-wide migration. Drive ban_std_pathbuf allowlist to zero: NormalizedPath everywhere, path-trimming only in excepted downstream files #1271 describes the broader goal but is closed.
• Keep the immediate exception file-specific because the existing linker API still requires raw PathBuf; redesigning production path plumbing inside a release-gate PR would broaden risk.

Related issues

• cross platform dylint checks for ci.yml and local repo ./lint #1501 tracks gaps in cross-platform full-Dylint enforcement.
• Drive ban_std_pathbuf allowlist to zero: NormalizedPath everywhere, path-trimming only in excepted downstream files #1271 is the prior workspace-wide PathBuf migration plan.