Keep Zed layer replays cohort-correct

[gauravtiwari]

Summary

• give the manual Cargo layer matrix a fixed reviewed adjacent source pair, independent of the continuously advancing rolling source
• move all eight committed plans to a fresh cache cohort carrying that pinned source identity
• judge target-layer presence explicitly instead of failing on unrelated dependency-cache misses
• handle target-only evidence when sccache is intentionally disabled

Why

The layer plans themselves are already on main, but two later proof runs exposed benchmark-boundary failures:

1. fail-on-cache-miss rejected target-only and combined jobs when a dependency archive missed even though the target snapshot restored. The workflow already verifies the target-layer hit explicitly, so aggregate strict-miss handling was testing the wrong boundary.
2. Target-only evidence correctly reported native_tool: null; the report treated that as an object and failed after both builds had succeeded.

The matrix also defaulted to the moving rolling source while its plan tags stayed fixed. A later manual dispatch could therefore restore an older cohort in the lane labelled cold. cargo-layer-source.env now owns the reviewed matrix pair (4e8057d… → d4010e9…), while benchmark-source.env continues to own the rolling chain.

No upstream Cargo command, runner architecture, runner label policy, or QEMU setting changes.

Verification

• python3 -m unittest discover -s test -v (9 tests)
• python3 scripts/verify-zed-release-recipe.py upstream
• actionlint .github/workflows/*.yml
• released BoringCache CLI 1.18.1 dry-run for all eight committed plans, verifying compiler and target-layer selection plus exact Zed primary/remote-server Cargo commands
• pinned head is the direct child of the pinned base
• git diff --check
• signed commit verified

A full fresh-runner matrix will be dispatched on this branch using the new cache cohort.