build(esp32): NightDriverStrip partitions CSV rejected by esp32-core-3.3.9 gen_esp32part.py (nvs 0x2000 < 0x3000)

[zackees]

Context

With #955 fixed (project-relative partitions CSV resolution, PR #958), NightDriverStrip demo's config/partitions_custom_noota.csv is now correctly found and passed to gen_esp32part.py. But the generator that ships with the resolved framework (esp32-core-3.3.9) rejects the CSV content:

WARN gen_esp32part.py failed: Partition nvs invalid: 'nvs' partition of type 1 and subtype 2 of this size (0x2000) must be flagged as 'readonly' (the size of read/write NVS has to be at least 0x3000)

NightDriverStrip's CSV declares nvs, data, nvs, 0x00b000, 0x002000 (8 KB). A newer esp-idf rule requires read/write NVS to be ≥ 0x3000 (12 KB). The workload's CSV predates that rule.

Consequences: partitions.bin is not produced, so the ESP32 fast-path fingerprint still can't persist for this project (blocks the whole-build short-circuit that would take #951's 2.1 s no-op rebuild down to ~0.5 s).

Open question — framework version parity

NightDriverStrip pins platformio/espressif32 @ ^6.12.0. fbuild resolved esp32-core-3.3.9. Worth confirming whether PlatformIO's espressif32@6.12.0 resolves the same arduino-esp32 core / gen_esp32part.py version — if PlatformIO builds this CSV fine, fbuild may be resolving a newer core than the pin implies (an A/B parity divergence), which is the real fbuild-side bug. If PlatformIO's 6.12.0 also rejects it, this is purely a stale workload CSV and belongs upstream in NightDriverStrip.

Acceptance criteria

• Determine which esp32 core espressif32@6.12.0 resolves under PlatformIO vs fbuild.
• If divergent: fix fbuild's platform→core resolution to match the pin.
• If matched: document that the workload CSV needs the nvs partition widened to 0x3000 (upstream / harness-local patch), out of fbuild scope.

Decisions

• Priority: P3 — does not affect perf(build): no-change rebuild recompiles the entire sketch + core variant (~103s; should be seconds) #951's merged no-op-rebuild win (that comes from the per-TU staleness path, not the fast-path fingerprint). Only blocks the incremental whole-build skip for projects with custom partitions.

Part of #942. Follow-up to #955 / PR #958.

[zackees]

Investigation complete — out of fbuild-core scope (stale workload CSV)

Per the acceptance criteria, determined what each side resolves:

• fbuild hardcodes pioarduino's platform: esp32_platform.rs PLATFORM_URL = pioarduino/platform-espressif32/releases/download/**stable**, PLATFORM_VERSION = "stable". There is no code that parses or honors the project's platform = espressif32 @ ^6.12.0 pin — the entire ESP32 path is intentionally built on pioarduino, which ships arduino-esp32 3.3.9 and its stricter gen_esp32part.py (read/write nvs must be ≥ 0x3000).
• PlatformIO platformio/espressif32 @ ^6.12.0 resolves the legacy arduino-esp32 2.0.x core, whose older gen_esp32part.py accepts NVS 0x2000.

So the resolution does diverge (fbuild 3.x vs the pin's 2.x) — but the divergence is a deliberate fbuild design choice (pioarduino is the maintained fork; platformio/espressif32 6.x is frozen on arduino-esp32 2.x), not an accidental resolution bug. The decision-tree's "fix fbuild's resolution to match the pin" branch would mean reverting fbuild's entire pioarduino/3.x ESP32 stack for one CSV — not desirable, and NightDriverStrip otherwise compiles + links + produces firmware.bin cleanly on 3.x (verified in #987/#988 e2e runs).

Conclusion: NightDriverStrip's config/partitions_custom_noota.csv (nvs … 0x002000) is stale for arduino-esp32 3.x. The fix is widening the nvs partition to ≥ 0x3000 (or flagging it readonly) upstream in NightDriverStrip or as a harness-local patch — out of fbuild-core scope. fbuild correctly passes the CSV and the framework correctly rejects it.

The broader question of whether fbuild should honor explicit espressif32@X version pins (rather than always pioarduino-stable) for A/B parity is a separate, larger design topic than this partition-CSV issue and is not blocking — filing separately if it proves worth pursuing. Closing #960 as out-of-scope per the acceptance criteria's "matched → document" branch.