setup-soldr: promote v0 floating tag to v0.9.82 (needs FastLED/fbuild canary)

[zackees]

Follow-up from #6 rounds 2E/2F. The template pins setup-soldr v0.9.82 by exact SHA (setup-soldr#539/#541 fixes: Dylint caches, source-SHA-free dylint-output key). The floating v0 tag was deliberately not moved: that requires a canary PR on FastLED and fbuild first. Track the canary runs (cache hit/miss, Dylint timings) and then the v0 move. Evidence: https://github.com/zackees/ci.yml/blob/main/docs/case-studies/template-python-rust-cmd.md (Round 2E/2F table).

[zackees]

Update, 2026-09-29: setup-soldr's v0 was moved to a07bab94f16124b5c6857b137a237a53a61e06d1 (v0.9.82) directly, with git push --force-with-lease against the old value 67ed401, at the user's explicit direction.

• Why directly: update-v0-tag.yml can only promote current main, which was already 869aa7b (#542, untagged, canary ci: canary setup-soldr 869aa7b exact SHA FastLED/fbuild#1572 still in flight). So it couldn't promote the tagged v0.9.82 release. Filed as zackees/setup-soldr issue (linked below).
• Evidence it's good: v0.9.82 had a green Setup Soldr Contract run on main (36506501080). kernal-api's first run on @v0 saved both Dylint layers (main run 36515654200). The next PR run restored both with an exact hit, and the Dylint job went 8m44s → 3m35s.
• Fleet float PRs: see Sweep: bump setup-soldr past v0.9.81 fleet-wide so Dylint caches save (RUST-004) #31.

[zackees]

The setup-soldr issue for promoting a released tag rather than main's tip: zackees/setup-soldr#546.

[zackees]

M2-38: canary for setup-soldr v0.9.84 (aa75de0, #545 on top of v0.9.83) is red, so v0 was not moved.

• Canary PR: ci: canary setup-soldr v0.9.84 (aa75de0) exact SHA FastLED/fbuild#1575 (label ci-full). It pins every setup-soldr use to aa75de0. Base is fbuild c2d08c87, which is the same commit the green v0.9.82-era canary fbuild#1572 ran on (run 36519257622, all green).
• ci-minimal run 36525555031 failed on both attempts (attempt 2 reran only the failed jobs), with the same two failures each time:
  • full / windows / Check (windows-latest): fbuild-core path::tests::canonicalize_lexical_memoizes_resolved_paths and canonicalize_lexical_does_not_memoize_the_missing_parent_fallback panic (path.rs:883/898).
  • full / ESP32 Dev / build: esp_bt.h:16:10: fatal error: ../../../controller/esp32/esp_bredr_cfg.h: No such file or directory (include farm).
  • Every other job passed: 90+ board builds, macOS, Linux, Dylint, docs, msrv, and acceptance.
• The fbuild source is identical to the green run, so the only intended difference is the setup-soldr SHA (869aa7b -> aa75de0, which adds #544 dylint-targets and #545). Restored cache state and the runner image can also differ between the two runs. I have not confirmed the cause. setup-soldr#545 only changes the post-step save gate, so a direct link is unlikely but unverified.
• update-v0-tag.yml requires successful CI selected coverage + full / Full coverage jobs, so promotion is blocked. Leaving this issue and fbuild#1575 open as evidence.

[zackees]

M2-39 outcome: setup-soldr v0.9.84 (aa75de0) canary FastLED/fbuild#1575 -- failures are unrelated to setup-soldr; v0 NOT promoted (stays 869aa7b).

Evidence:

• The canaries did not test the same fbuild tree. Green run 36519257622 checked out c2d08c8 = the old canary base bcab795 + pin. Failing run 36525555031 (attempts 1 and 2) checked out b8257df = current fbuild main f04e34e + pin. Diffing f04e34e...c2d08c8 shows main added the canonicalize_lexical memo (perf(esp32s3): cold build 1.55x slower than PlatformIO — bloated -I list (+55% per TU), serial sketch phase, pre-compile serial overhead FastLED/fbuild#1537, crates/fbuild-core/src/path.rs) plus its new tests, and the PIO-CPPPATH/include-farm ESP32 include rework (sdk_paths.rs, include_farm.rs). The green tree did not have either change.
• Runner images match in both runs: windows win25-vs2026/20260922.246, ubuntu ubuntu24/20260920.314. An image rollover is ruled out.
• The ESP32 error include-farms/.../esp_bt.h:16:10: fatal error: ../../../controller/esp32/esp_bredr_cfg.h also appears in run 36514030389 (canary 8703b0d3 on a newer base, parent c896370c). That run used the old, previously green setup-soldr 869aa7b, so setup-soldr is not the cause. The include-farm flattening breaks relative ../../../ includes.
• On Windows, the failing tests are exactly the new memo tests (canonicalize_lexical_memoizes_resolved_paths path.rs:883, ..._does_not_memoize_the_missing_parent_fallback path.rs:898). The green tree does not contain them.
• fbuild main pushes run only ci-minimal without full, so main has no signal for these jobs. They are latent regressions on fbuild main, not flakes.
• setup-soldr #544 (dylint targets) and #545 (multi-session save gate) only change soldr's cargo/dylint cache save and restore. The ESP32 job's restored caches are fbuild's own fbuild-toolchain-* actions/cache entries, and the failure is in a C++ include farm under ~/.fbuild. Neither change can affect it.

Gate: update-v0-tag.yml -> scripts/verify-v0-promotion.py requires a canary ci-minimal run with conclusion success and a green full / Full coverage job. On current fbuild main that cannot happen until fbuild fixes both regressions. I did not re-base the canary onto bcab795, because the brief allowed pushes to #1575 only for a setup-soldr root cause. Next step: (a) fix the two fbuild main regressions, or (b) re-run the canary on the last-green base bcab795 + the aa75de0 pin, as was done for 869aa7b, then dispatch update-v0-tag.yml with target aa75de0e55ed9751cdee04bf5200c46fe8d59851. FastLED/fbuild#1575 is closed without merging.