fix(esp32): BIN artifact cache ignores which esptool produced the bin — caller-PATH requests can reuse a stale firmware.bin (gap in #1236)

[zackees]

Gap left by #1236 (the merged #1219 implementation), originally flagged and confirmed by CodeRabbit on the parallel PR #1231.

Problem

Esp32Linker::convert_firmware now applies the per-request caller PATH to the esptool spawn (esp32_linker.rs ~:489, since #1236), but can_reuse_bin / BinArtifactCache do not record anything about which esptool produced the cached firmware.bin. Two requests with different caller PATHs can resolve bare-name esptool to different binaries (different versions, venv vs system), yet the second request reuses the first one's firmware.bin and never runs its own tool.

Fix (validated on the closed PR #1231, needs porting to the #1236 code shape)

• BinArtifactCache gains #[serde(default)] esptool_fingerprint: String.
• Fingerprint rule: empty string when esptool_bin is an absolute provisioned path or there is no caller_path (exactly today's behavior, so existing caches stay valid); otherwise a 16-hex-char SHA-256 prefix of the caller_path string.
• Record it when writing the cache and compare it in can_reuse_bin (struct equality covers it).
• No global BUILD_FINGERPRINT_VERSION bump: serde(default) deserializes old records as "", which continues matching the absolute-path expectation and mismatches any caller-PATH fingerprint — invalidation in the correct direction only.

Regression tests (from #1231, to port)

• bare_name_esptool_bin_reuse_is_keyed_by_caller_path — same caller PATH reuses; different caller PATH does not; None caller PATH does not reuse a caller-PATH bin.
• absolute_esptool_bin_reuse_ignores_caller_path — provisioned path keeps caching, fingerprint recorded as empty.

Defaults chosen by the drafting agent are listed inline — edit as needed.