native link cache: identical second build misses with miss_reason=source #9378

Symptom

native_link_cache::native_compile_skips_link_on_identical_second_build fails:
a second, byte-identical build is expected to hit the caches and instead misses
entirely.

build_cache:   { "hit": false, "miss_reason": "source" }
codegen_cache: hits = 0   (expected 1)

miss_reason: "source" means the second build considered the source changed
when it had not.

Not a regression from the current release window

Confirmed with clean builds (cargo clean first — an incremental target dir
across checkouts produces false verdicts here):

So it predates the window and is independent of #9226.

Why it went unnoticed

cargo-test-perry shards run only in the full tier, never on main. In the
Aug-31 full tier this test never executed: it appears in shard 6's enumeration
but never as Running tests/native_link_cache — the shard died earlier, on
fire_and_forget_fetch_survives_recompile. There is no baseline for it in
recent history.

Reproduces locally

macOS/aarch64 as well as ubuntu-latest:

cargo build -p perry -p perry-runtime-static -p perry-stdlib-static
RUST_TEST_THREADS=1 cargo test -p perry --test native_link_cache

(build the -static wrappers first — otherwise a stale archive yields a
commit-coherence refusal rather than a test result)

Worth checking

If the cache genuinely misses on an unchanged source in normal use, the cost is
not only this test — every incremental perry compile would be re-linking
needlessly. Worth confirming whether the defect is in the test's fixture or in
the cache key itself.

Blocking

full-suite-gate fails on it, so it blocks any release cut until fixed or
triaged.