fix(gate): skip the Rust build cache on a repo with no Cargo manifest

[forkwright]

Finding

Swatinem/rust-cache shells out to cargo metadata, which fails outright on a repo with no Cargo.toml:

commandFailed: {
command: 'cargo metadata --all-features --format-version 1 --no-deps',
stderr: 'error: could not find `Cargo.toml` ...'
}

The step ran unconditionally, so it failed the entire gate for a cache it could never have populated.

Not every consumer is a Rust repo

typikon calls this gate with fmt_cmd: "true", clippy_cmd: "true", nextest_cmd: "true" and uses check_cmd for its own non-Rust checks. That is deliberate — its caller carries a comment saying the repo "has no Rust code of its own". Confirmed: there is no Cargo.toml anywhere in typikon's tree.

Its gate has therefore been failing on a cache step rather than on anything it actually checks. Same shape applies to any other non-Rust consumer.

This is the fleet's own standard as a defect rather than as prose — FLEET-REPO-SETUP.md says adding Rust CI to a repo with no crates "produces a job that fails looking for a build, on every push, forever." That is exactly what happened here, from the reusable's side rather than the consumer's.

The guard

A positive test for what the cache actually needs. A repo that gains Rust later picks the cache back up with no further change; a repo that never had it stops being asked for one.

Verification

Both event-shape checkers pass against the edited file:

check_gate_evaluation.py → 10/10 cases behaved as specified. EXIT=0
check_event_shape_guards.py → OK: 16 pull_request-only values examined, none reaches git unguarded. EXIT=0

YAML parses; the five jobs are unchanged.

Note for consumers

This reaches repos that float @main on their next push. typikon currently pins this workflow by SHA with a # main comment — the shape that cannot be bumped, since this repo publishes no tags — so it will not receive the fix until that pin moves. That is being handled separately.