fix(deps): bump cmov 0.5.3 -> 0.5.4 (GHSA-3rjw-m598-pq24)

[alphaqiu]

Summary

Resolves Dependabot alerts #2 and #3. These are the same vulnerability (GHSA-3rjw-m598-pq24 / CVE-2026-50185, cmov < 0.5.4), each generated once per lockfile:

Alert	Lockfile	Workspace
#2	Cargo.lock (root)	oak-keyring release binary ok
#3	tools/okb-gen/Cargo.lock	okb-gen dev tool (separate workspace)

Dependabot reports per (lockfile, dependency), so one vuln in two lockfiles yields two alerts.

Root cause

• tools/okb-gen is an independent Cargo workspace (its Cargo.toml depends on oak-keyring via path = "../..", but it's not a member of a root [workspace]). It therefore carries its own Cargo.lock.
• Both workspaces resolve the same transitive chain to the vulnerable version:
  oak-keyring -> keepass 0.12.9 -> digest 0.11.3 -> ctutils 0.4.2 -> cmov 0.5.3

The vulnerability

cmov's aarch64 Cmov/CmovEq inline asm assumed zero-extension of sub-register-width loads, but the high bits are undefined per the Rust reference. After a narrowing cast, csel can pick the wrong branch, so constant-time primitives return wrong results. Fixed in cmov 0.5.4.

Impact: aarch64-specific. release.yml builds ok for aarch64-apple-darwin and aarch64-unknown-linux-gnu, so alert #2 has real exposure; #3 (okb-gen) is a dev-only tool.

Changes

• Cargo.lock: cmov 0.5.3 -> 0.5.4
• tools/okb-gen/Cargo.lock: cmov 0.5.3 -> 0.5.4 (also re-syncs the stale oak-keyring path-dep preview.1 -> preview.2)

Verification

• cargo build --release on root workspace: OK
• cargo test on root: 2600 unit + integration/e2e/snapshot suites, 0 failures
• cargo build + cargo test on okb-gen: OK
• cargo tree -i cmov resolves to 0.5.4 in both workspaces

Follow-up (not in this PR)

To prevent recurrence, consider merging tools/okb-gen into a root [workspace] (share a single Cargo.lock) so future transitive vulns produce one alert instead of two.

Dependabot alerts #2 #3