fix(esp32): key the bin artifact cache on which esptool produced it (#1238)

[zackees]

Closes #1238

Cache-correctness follow-up to #1236 (flagged by CodeRabbit on the superseded #1231).

Problem

convert_firmware applies the per-request caller PATH to bare-name esptool spawns (since #1236), but BinArtifactCache recorded nothing about which esptool produced firmware.bin. Two requests whose PATHs resolve different esptool binaries (venv vs system, different versions) could share one cached bin — the second never runs its own tool.

Fix

BinArtifactCache gains #[serde(default)] esptool_fingerprint: String, computed in the linker:

• "" when esptool_bin is a provisioned absolute path, or when no caller PATH was forwarded — byte-for-byte the pre-fix(build): thread caller PATH per request into daemon tool resolution (#1219) #1236 cache semantics, so existing caches stay valid and no BUILD_FINGERPRINT_VERSION bump is needed (old records deserialize as "" and only mismatch actual caller-PATH fingerprints — invalidation in the correct direction only).
• Otherwise a 16-hex SHA-256 prefix of the caller PATH string.

Struct equality in can_reuse_bin covers the comparison; the fingerprint is recorded on every cache write.

Tests (as specified in the issue)

• bare_name_esptool_bin_reuse_is_keyed_by_caller_path — same PATH reuses; different PATH doesn't; None PATH doesn't reuse a caller-PATH bin.
• absolute_esptool_bin_reuse_ignores_caller_path — provisioned tool keeps caching across differing PATHs, fingerprint recorded empty.

Validation

• soldr cargo clippy -p fbuild-build-esp -p fbuild-build-engine --all-targets -- -D warnings — clean.
• soldr cargo test -p fbuild-build-esp — 100 passed, 0 failed; -p fbuild-build-engine build_fingerprint — 27 passed.
• Only one BinArtifactCache construction site exists (the linker's own), so no other callers need the field.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@zackees, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 41 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: a137d60f-4b44-4eb0-88ed-02a8d6859e33

📥 Commits

Reviewing files that changed from the base of the PR and between 0d1a02b and 331ac51.

📒 Files selected for processing (2)

• crates/fbuild-build-engine/src/build_fingerprint/mod.rs
• crates/fbuild-build-esp/src/esp32/esp32_linker.rs

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[zackees]

Superseded by #1240, which merged as 83a327e about an hour before this PR was opened and closed #1238. The implementations are equivalent (same serde-defaulted esptool_fingerprint field, same empty-for-provisioned/hash-for-bare-name rule, same two regression tests from the issue spec); #1240 additionally landed the end-to-end run_command overlay-resolution test. Both regression tests validated green on merged main. Nothing here is lost — closing to keep the queue clean. (Symmetric with #1231, which was superseded by #1236 the same way — we now have two data points that two sessions working the same repo need to claim issues before implementing; see the coordination note on #1238.)