fix(actions): prune cargo cache before saving

[goastler]

save_cargo_cache uploads ~/.cargo and target/ verbatim. On a local Protect checkout that tree is 17 GB — ~7.5 GB of it incremental state, ~6 GB deps/ with a dozen-odd link artifacts over 100 MB each. GitHub caps a repo's total cache at 10 GB and evicts LRU, so an entry that size never really saves and thrashes out every other cache in the repo; the existing "delete all but the latest key" step is a symptom of that. It also costs disk on restore, before the build has compiled anything — part of what tipped hosted runners into ENOSPC on Protect#410.

Adds a prune step before the save, doing what Swatinem/rust-cache does:

• incremental dirs — per-machine, per-working-copy state that the restoring runner cannot use. Removed via find rather than a ** glob, since ** isn't recursive without globstar and nested workspaces have their own target/.
• ~/.cargo/registry/src — regenerated from the .crate archives in registry/cache, which are kept. Roughly halves the registry.
• the workspace's own artifacts — rebuilt every run anyway, so caching them only ages the entry. Matched by package name from cargo metadata --no-deps so the dependency artifacts beside them, which are the entire point of the cache, survive.

Prints before/after MB.

Not delegating to Swatinem/rust-cache wholesale: it has no equivalent of the self-hosted gating in restore_cargo_cache, nor of this repo's run_id-keyed save + wildcard restore-keys scheme.

Related: prosopo/github_actions#4, Protect#450.