[juan-malbeclabs]

Closes the detection gap behind #155. Merge after #151, which is what actually repairs Cargo.lock on main — with a broken lock this PR's own CI is (correctly) red.

Summary

• Adds --locked to the three cargo invocations in rust.yml (build, clippy, test).
• The Dockerfile's cargo build --release --locked was the only place the lock was enforced. CI re-resolved silently, so a Cargo.lock that Cargo would have to rewrite passed every check and first surfaced days later as a failed GHCR publish — three days of failed image publishes, with :mainnet-beta left on the 0.38.0 client base across a doublezero release (Image publishes have failed since 2026-09-08: Cargo.lock on main is unusable with --locked #155).
• A stale or internally inconsistent lock now fails the PR that introduces it, on the PR run rather than on a release.

This closes the detection gap, not the cause: two Dependabot PRs whose locks are each valid against their own base still merge into an invalid one. Requiring branches to be up to date before merging (or a merge queue) is the branch-protection change that prevents that — a repo setting, not code.

Testing Verification

• Reproduced the gap at main (e258968): cargo build --workspace --release succeeds while cargo build --workspace --release --locked fails with cannot update the lock file. With this change, that commit would have gone red on the PR that introduced it instead of three days later on a publish.
• Verified cargo build --workspace --release --locked succeeds against deps: pin past the yanked chacha20 0.10.1 #151's repaired lock.