ci: enforce --locked on workspace cargo invocations

[Senorespecial]

Summary

Adds --locked to the two workspace-resolution cargo invocations in .github/workflows/ci.yml so lockfile drift surfaces as a hard CI failure instead of being silently regenerated by Swatinem/rust-cache@v2 + cargo's resolver.

Why

Sweep-of-CI parity earlier this session confirmed:

• Local cargo check --workspace exits 0 everywhere I tested (PIPESTATUS[0]-aware, not $? through | tail -N). The "duplicate key workspace" cargo message previously seen was a $? misread, not a real Cargo.toml parse error.
• However, cargo clippy --workspace --all-targets, cargo test --workspace, and similar workspace-resolution commands historically do NOT pass --locked, which means a stale or drifted Cargo.lock could be silently regenerated by cargo when the cache is warm. That is how local-vs-CI lockfile byte differences accumulate without anyone noticing until a real crate-version mismatch lands.

--locked flips that: if Cargo.lock does not match the committed version, the cargo invocation fails immediately with a clear "differs from current lock file" message. Failure mode becomes "DRIFT -> PR red" instead of "DRIFT -> silent regen -> merges fine, then cargo audit complains".

Diff

       - name: Clippy
-        run: cargo clippy --workspace --all-targets -- -D warnings
+        # --locked makes lockfile drift a hard failure in CI rather than cargo silently
+        # regenerating Cargo.lock from manifests, which previously masked publisher-side out-of-sync
+        # changes. See Octo-Protocol-org/Octo-Protocol#33 (sibling fix for toolchain-channel pinning).
+        run: cargo clippy --workspace --all-targets --locked -- -D warnings

       - name: Test
-        run: cargo test --workspace
+        # --locked: same rationale as Clippy above -- fail loudly on lockfile drift.
+        run: cargo test --workspace --locked

What is intentionally NOT touched

• cargo fmt --all -- --check -- cargo fmt does not resolve dependencies; --locked has no semantic meaning there.
• EmbarkStudios/cargo-deny-action@v2 -- first-party action; uses its own advisory database, not workspace Cargo.lock.
• rustsec/audit-check@v2 -- same, first-party action.
• gitleaks/gitleaks-action@v2 -- scans git history, not cargo.

Acceptance criteria

• cargo clippy --workspace --all-targets --locked -- -D warnings succeeds in CI.
• cargo test --workspace --locked succeeds in CI.
• A test PR that intentionally mutates Cargo.lock to a no-op diff fails its Check job with the "lock file ... needs to be updated" message rather than silently regenerating.

References

• ci: install of cargo-audit errors out with stable-x86_64-pc-windows-msvc on ubuntu-latest — wire rust-toolchain channel for runners to stable-x86_64-unknown-linux-gnu #33 (sibling: toolchain-channel pinning).
• PR feat(dashboard): add gas sponsorship status indicator to wallet cards (#14) #31 (Senorespecial/Octo-Protocol -> Octo-Protocol-org/Octo-Protocol): feat(dashboard): add gas sponsorship status indicator to wallet cards (#14) #31 -- its PR body note about an inherited cargo check --workspace failure is the same $? misread, not a real workspace issue.
• Earlier followup with full parity table in this conversation.