fix(ci): commit Cargo.lock for reproducible builds

[ohdearquant]

What changed

• Dropped the Cargo.lock entry from .gitignore and committed crates/Cargo.lock.
• Added a lockfile phase to scripts/ci.sh (cargo check --workspace --locked), wired into the CI workflow's full suite (runs on every push and PR).

Why

crates/Cargo.lock was gitignored, so dependency resolution floated per checkout: fresh clones and CI always resolved the latest semver-compatible versions, but an existing local checkout stayed pinned to whatever was resolved when its lockfile was first generated. Two consequences:

• Security-advisory pins (e.g. the crossbeam-epoch 0.9.20 fix for RUSTSEC-2025-0119, reached transitively via rayon) could not land as a reviewable diff — there was nowhere in the repo to put the pin.
• Existing local checkouts had no mechanism to detect that their resolution had drifted from what CI (and any fresh clone) was building.

For a binary-shipping repo, the standard guidance is to commit the lockfile: builds become reproducible, dependency state is auditable, and advisory bumps land as ordinary one-line PRs. The lockfile CI phase closes the other half of the gap — a manifest change that isn't matched by a Cargo.lock update now fails the build (--locked) instead of silently re-resolving and drifting again.

Trade-off — floating-lock canary

Committing the lock removes one incidental signal a floated lockfile provided: a fresh resolve would, on its own, surface a newly yanked or semver-broken transitive dependency the next time anyone resolved from scratch. That upstream-breakage visibility is recovered separately by #1072 (a scheduled weekly job that resolves with the lock ignored and reports drift), so the reproducibility win here does not cost us that early warning — it just moves it to a dedicated, scheduled check instead of an unpredictable side effect of every fresh checkout.

Test evidence

From crates/:

$ cargo check --workspace --locked
   ...
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 2m 13s

Verified the gate actually catches drift: reverting the crossbeam-epoch entry in Cargo.lock to 0.9.18 and re-running cargo check --workspace --locked fails with error: checksum for crossbeam-epoch v0.9.18 changed between lock files — confirming the committed lock is pinned to the patched version and that --locked rejects a mismatched lock instead of silently re-resolving.

Crate-scoped gate (touched crate closest to the issue's dependency path — khive-vamana pulls rayon -> crossbeam-epoch):

$ cargo test -p khive-vamana
test result: ok. 31 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

$ cargo clippy -p khive-vamana --all-targets -- -D warnings
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 1m 05s

$ cargo fmt -p khive-vamana -- --check
(no output — clean)

Closes #920

[oceanwaves630]

Approved at b116449. Read the ci.yml/ci.sh/.gitignore diff: the lockfile phase runs first in run_all and on every PR's ubuntu leg (full suite), so a manifest change without a matching lock update fails at PR time rather than post-merge. Lock commit policy per the repo ruling; canary trade tracked in the referenced follow-up.