Inconsistent Cargo.lock handling across Rust examples — pick one policy

[marc0olo]

Problem

The repo currently has a three-way inconsistency around Cargo.lock:

• The root .gitignore ignores Cargo.lock.
• 30 examples commit it anyway (tracked files override the ignore): rust/backend_wasm64, rust/basic_bitcoin, rust/basic_ethereum, rust/candid_type_generation, rust/canister-info, rust/canister-snapshot-download, rust/canister-snapshots, rust/canister_logs, rust/exchange-rates, rust/face-recognition, rust/guards, rust/icp_transfer, rust/image-classification, rust/inter-canister-calls, rust/low_wasm_memory, rust/parallel_calls, rust/performance_counters, rust/periodic_tasks, rust/photo_gallery, rust/qrcode, rust/query_stats, rust/receiving-icp, rust/send_http_get, rust/send_http_post, rust/simd, rust/threshold-schnorr, rust/unit_testable_rust_canister, rust/who_am_i, rust/x509, and motoko/parallel_calls (Rust load-test tool).
• The remaining Rust examples (rust/hello_world, rust/vetkeys/*, rust/evm_block_explorer, rust/llm_chatbot, rust/threshold-ecdsa, ...) do not commit it.

Current impact: none of the committed locks are used by builds

• The @dfinity/rust recipe (icp-cli-recipes) has a locked: boolean option that appends --locked to cargo build — but it defaults to false and no example sets it.
• Three examples use custom cargo build steps in icp.yaml (image-classification, face-recognition, composite_query); none pass --locked/--frozen.
• The only --locked flags in the repo are cargo install --locked for CI tools (candid-extractor, wasi2ic), which use the tool's own bundled lock file, not the example's.

So today the committed locks only pin what developers get locally; CI always resolves fresh dependencies.

Options

(a) Commit Cargo.lock everywhere and make it load-bearing

• Remove Cargo.lock from the root .gitignore, commit the missing locks, set locked: true in every rust recipe config (and add --locked to the three custom build steps).
• Pro: reproducible builds; local dev matches CI.
• Con: locks go stale unless updates are automated (Renovate/Dependabot); more churn in PRs.

(b) Untrack all locks and stay lock-free

• git rm --cached the 30 tracked locks; keep the root gitignore entry.
• Pro: zero maintenance; CI always builds against the latest compatible dependencies, catching upstream breakage early — arguably the right behavior for an examples repo that wants to stay current.
• Con: builds are not reproducible; a bad upstream release can break CI for unrelated PRs.

Either option is better than the current mixed state.

[marc0olo]

The same inconsistency exists on the Motoko side, in a smaller dose: the root .gitignore ignores mops.lock, but exactly one example commits it anyway — motoko/basic_bitcoin/mops.lock. All other Motoko examples are lock-free.

One nuance that makes it slightly more than cosmetic: when the CI env var is set, mops install defaults to --lock check, which fails if a committed lockfile is stale. So a committed mops.lock can fail CI after a mops.toml edit unless mops install --lock update is run alongside it (mops also warns this auto-detection is deprecated and will be removed in v3).

Whatever policy is chosen here should cover both Cargo.lock and mops.lock.