Release automation ships a stale Cargo.lock: lock-sync the release PR and build --locked in CI #242

Every release-please PR bumps the five workspace crate versions in the Cargo.tomls but never touches Cargo.lock, so each release merge re-creates manifest/lock drift. Current state, verified by execution: main's Cargo.lock records all five workspace crates at 0.5.1 while the manifests say 0.6.0 (and 0.7.0 once #240 merges), and cargo metadata --locked on main exits 101 ("cannot update the lock file because --locked was passed").

Consequences:

• A --locked build from any release tag fails, so the lockfile we ship is dead weight for reproducible builds.
• The release binaries are built from a resolver-fresh dependency set, not the committed lock, which quietly weakens the lock's supply-chain value.
• Any plain cargo build on a drifted checkout rewrites the lock's version fields, so contributors keep hitting mystery-dirty trees (this has already produced repeated hand-sync commits, which fix it only until the next release merges).

Hand syncs are the wrong tool: the drift is reintroduced by automation, so the fix has to live in automation.

Proposed fix:

1. A lock-sync step in the release flow so the release PR itself carries the Cargo.lock bump (cargo update --workspace on the release branch), making the tagged tree internally consistent.
2. Build with --locked in PR CI so any future manifest/lock drift fails loudly at PR time instead of surfacing as dirty trees later.

Sequencing note: the --locked CI gate can only land together with (or after) a lock sync, and a sync commit must postdate the 0.7.0 release merge or it re-breaks immediately.