Fix Cargo.lock issues and add --locked in CI

[andyleiserson]

There were some Cargo.lock inconsistencies due to changes that were tested/merged in parallel (I believe #8229 and #8263). This fixes them. It also adds --locked to CI to enforce better Cargo.lock hygiene. Note that doing so wouldn't have prevented this from happening, it just means that we would have noticed right away because the 2nd PR would have broken trunk.

Testing
Build still works in CI.

Squash or Rebase? Rebase

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy --tests. If applicable, add:
  • --target wasm32-unknown-unknown
• Run cargo xtask test to run tests.
• If this contains user-facing changes, add a CHANGELOG.md entry.

[ErichDonGubler]

LGTM overall! One non-blocking nit.

[ErichDonGubler]

nitpick: This windows-sys change seems like unnecessary churn, and dependent on what you were doing. AFAIK rustix allows windows-sys 0.61.

[cwfitzgerald]

This seems to be a weird problem where cargo update sometimes resolves things differently on different... (platforms?) I'm not sure. I've seen this kind of thing a lot.

[Wumpf]

I've seen it exclusively with windows-sys and one more windows related crate. really strange

[kpreid]

https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/cargo.20updating.20unrelated.20parts.20of.20the.20lockfile.3F

[andyleiserson]

In this case, if I revert the windows-sys change, cargo --locked rejects the lockfile, so I'm going to leave the change, although it's certainly annoying.