fix(ci): drop the dry-run package dir before the cargo cache is saved

[spacedevin]

The Rust crate job posts four ##[error] annotations on otherwise green runs — most recently on the #16 merge:

ENOENT: no such file or directory, opendir '…/crate/target/package/deckfile-0.1.0/tests/trybuild'
ENOENT: no such file or directory, opendir '…/crate/target/package/deckfile-0.1.0/tests/target'

Cause

They come from Post Cache cargo, not from any build step — every job passes and the crate packages fine.

cargo publish --dry-run leaves an extracted copy of the crate at target/package/deckfile-<version>/. That copy contains a tests/ directory (just conformance.rs). rust-cache prunes target/ before saving it, sees tests/, and goes looking for the trybuild layout — tests/target and tests/trybuild — which this crate has never had.

Reproduced locally: after cargo publish --dry-run --allow-dirty, target/package/deckfile-0.1.0/tests/ exists holding only conformance.rs, and both paths rust-cache wants are absent.

Why it looks sporadic

rust-cache skips the prune entirely on a cache hit, so the annotations only appear on a miss:

run	post-cache step	annotations
#16 merge	... Cleaning …/crate/target ...	4
#15	no cleaning lines (cache hit)	0
#14	pruned	4

Each occurrence lines up with a change to the emitted crate moving the cache key. #16 regenerated crate/ (new Wavetable module, new Wave facade struct, new conformance test), so it missed and the latent bug surfaced again.

Fix

Remove the dry-run output once the check has served its purpose — nothing should be caching it. The check itself is unchanged.

cache-targets: false on the rust-cache step would also silence it, but at the cost of the build cache, so this is the better trade.

Worth fixing rather than muting: a green run that reports four errors teaches everyone to skim past annotations, which is exactly when a real one gets missed.

[spacedevin]

One caveat on this PR's green run, so it isn't over-read: that run got a cache hit (Post Cache cargo logged only Cache up-to-date.), so the prune never ran and the failure path was never exercised. Zero annotations there is expected either way and proves nothing on its own.

What is verified is the mechanism, locally:

• after cargo publish --dry-run --allow-dirty, crate/target/package/deckfile-0.1.0/tests/ exists containing only conformance.rs, and both paths rust-cache asks for — tests/target, tests/trybuild — are absent, which is exactly the reported ENOENT
• rm -rf target/package removes the directory the prune walks into

So the fix deletes the input to the failure rather than suppressing the symptom. It'll be demonstrated for real on the next cache miss — the next run where the emitted crate changes, which is also the only kind of run that ever showed the problem.