ci: write Cargo caches only from main and share redundant entries

A cache entry belongs to the branch that wrote it, so saving from pull
requests gave every open pull request its own full set. The first run of the
split gate wrote 9.4GB across eight entries against GitHub's 10GB per-repo
ceiling, which meant two or three concurrent pull requests would evict each
other's entries continuously and quietly send the legs back to cold builds --
undoing the speedup the split just bought.

Legs now restore with actions/cache/restore and save with actions/cache/save
gated to `github.event_name == 'push'`, both at the digest already pinned for
actions/cache, so no new action enters the trust set. Pull requests read
main's entries through restore-keys and write nothing, so the repository holds
one set instead of one per branch.

Loopback cases 1-3 are all debug-profile builds of the same binaries and were
storing three near-identical 767MB copies. They now share one entry, with case
1 nominated as its writer and case 4 owning the release entry, so no two
concurrent matrix legs race to reserve the same key.

Together that takes main's steady-state footprint from 9.4GB to roughly 6.3GB.

The policy checker gains the matching invariants: a step-level `if` is now
permitted only on a cache save and only with an approved push-gated condition,
an unconditional save is rejected outright, a restore must be paired with a
save under the same key and paths, the restore must carry the id the save
condition reads, and the combined read-write cache action may only ever cache
the one-megabyte cargo-zigbuild binary. Suite grows from 51 tests to 59.

commit

1af9ebe47dcdd84c5f79a1bfd6d7960fcdb2f83e

parent

8941f0b20bbeaecf6b7b87dfd1a84624325e3f99

author

Dami <dami.etoile@gmail.com>