Add Cargo.lock to version control for reproducible builds

[coderabbitai]

Summary

The bootstrap crate (and possibly other workspace members) use semver-range dependency specifiers (e.g. pest_generator = "2.1.1", quote = "1.0") but no Cargo.lock is committed to the repository. This means the generated meta/src/grammar.rs can change between CI runs as upstream dependencies release new versions, which undermines the check-grammar-sync CI gate introduced in #1159.

Recommended Fix

Follow the Cargo FAQ guidance on checking in Cargo.lock:

1. Run cargo generate-lockfile (or simply cargo build) at the repository root.
2. Commit the resulting Cargo.lock file.
3. Add a CI step or update existing steps to ensure the lockfile stays up to date.

Context

Raised during review of #1159 (comment: #1159 (comment)) by @konstin.
This is a pre-existing condition, not introduced by #1159, but it is now more visible because grammar.rs is kept in tree and verified in CI.

References

• https://doc.rust-lang.org/cargo/faq.html#why-have-cargolock-in-version-control
• Keep grammar.rs in tree #1159
• Generated grammar.rs means that sources can't be verified #1158

[tomtau]

I worry it may cause a big churn of dependencies (and Cargo.lock merge conflicts).

The main culprit of non-determinism is reqwest in pest_debugger which pulls in a lot of transitive dependencies:

pest/debugger/src/main.rs

Line 412 in 587f8e5

fn check_for_updates(client: Client) -> Option<String> {

Before considering Cargo.lock to the repo, it'd be better to look at this issue first. I assume there are three possible ways of sorting it out:

1. separating out pest_debugger to a different repository
2. replacing reqwest with something more lightweight (but HTTPS is complex, so not sure if e.g. ureq would make much difference)
3. removing that auto-update checking mechanism