chore(repo): include cargo lock in release please

[RogerLamTd]

No description provided.

[claude]

Claude finished @RogerLamTd's task in 2m 6s —— View job

---

PR Review: chore(repo): include cargo lock in release please

• Gather context
• Review changes
• Post feedback

---

Summary

This PR adds Cargo.lock as an extra-file for all four Rust packages in release-please config, so version bumps propagate to the lock file during releases.

Changes Reviewed

release-please-config.json — adds Cargo.lock extra-file entries for:

• packages/ejector
• packages/overseer-rs
• packages/taiko-client-rs (+ adds crates/bindings/Cargo.toml)
• packages/urcindexer-rs

Feedback

Correctness: The JSONPath filter !@.source is the right way to distinguish local workspace packages from crates.io registry packages in Cargo.lock. External packages have source = "registry+..." fields; local ones don't. This is a well-targeted filter.

taiko-client-rs coverage: The JSONPath covers all 9 workspace members (taiko-client, bindings, driver, preconfirmation-driver, whitelist-preconfirmation-driver, proposer, protocol, rpc, test-harness) — confirmed this matches the workspace Cargo.toml members exactly.

crates/bindings/Cargo.toml addition: Valid. bindings has a hardcoded version = "2.0.0" (not version.workspace = true), so it needs an explicit extra-file entry to get updated during releases.

Generic names (rpc, protocol, driver): These names are generic enough to appear in third-party crates, but the !@.source guard handles that correctly. Currently each appears exactly once in the lock file.

One thing to verify manually: Release-please's TOML updater needs to support the !@.source JSONPath negation filter. This syntax is supported by jsonpath-plus (which release-please uses), but it's worth testing with an actual release to confirm the filter evaluates correctly against TOML-parsed structures.

Verdict

LGTM. Clean, complete, and the approach is sound.