fix(release): sync the module workspace lockfile on a version bump

[senamakel]

Summary

main is currently unbuildable under --locked in the module workspace, and the
v0.2.0 tag with it. This fixes that and the workflow step that caused it.

There are two Cargo worlds in this repo: the root workspace, and
crates/tinymemory-module, which is its own workspace root with its own
Cargo.lock (see the root Cargo.toml comment for why it has to be). The module
depends on the root crate by path, so when the release bumped the root version to
0.2.0 and updated the root lockfile, the module's lockfile kept recording
tinymemory 0.1.0.

native-bundles builds with --locked, so all eleven bundle jobs failed:

error: cannot update the lock file …/crates/tinymemory-module/Cargo.lock
       because --locked was passed to prevent this

The tag had already been pushed at that point, which is the part worth fixing
properly rather than by hand.

Related issue

Follow-up to #6.

API or behavior changes

None. A lockfile sync and two CI/workflow changes.

Validation

Commands actually run, with their outcome:

• cargo fmt --all -- --check — clean
• cargo clippy --all-targets --all-features -- -D warnings — clean
• cargo build --all-targets --all-features — clean
• cargo test --all-features — green

The one that matters, reproducing the release failure and then its absence:

$ cargo build --locked --manifest-path crates/tinymemory-module/Cargo.toml   # on main
error: cannot update the lock file … because --locked was passed
$ cargo update --manifest-path crates/tinymemory-module/Cargo.toml -p tinymemory --precise 0.2.0
    Updating tinymemory v0.1.0 -> v0.2.0
$ cargo build --locked --manifest-path crates/tinymemory-module/Cargo.toml
    Finished `dev` profile

Tests

Not unit-testable — it is a lockfile-consistency property. Guarded in CI instead,
which is the actual fix here:

• ci.yml's module job now builds with --locked, matching how the release
  builds this crate. This is what would have caught it on the PR: without it a
  stale module lockfile passes CI and fails the release, and the failure lands
  after the tag is pushed, when it is most expensive.
• The release bump step updates both lockfiles and then asserts consistency
  with cargo metadata --locked before tagging, so a future drift of this shape
  fails in the tag job rather than eleven jobs downstream.

Both carry a comment naming the two-lockfile cause, since "add --locked" reads
like a style preference otherwise.

Documentation

Comments on both changed steps. The root Cargo.toml already explains why the
module is a separate workspace; this adds the consequence that falls out of it.

Note on the orphaned tag

v0.2.0 exists and has no GitHub release — the bundle jobs never produced
assets. This PR does not touch it. The next release will be v0.3.0; v0.2.0
can be deleted or left as a marker, but nothing consumes it either way, and
deleting a tag on the canonical repo is not something to do as a side effect of
a lockfile fix.

Checklist

• The change is focused on one logical change
• No new #[allow(...)], #[ignore], or relaxed lints
• No secrets, tokens, or .env contents in the diff or the description

[coderabbitai]

Warning

Review limit reached

@senamakel, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 2 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 5ab0e967-dffd-4650-90f9-d4fc1dcaec30

📥 Commits

Reviewing files that changed from the base of the PR and between 77ebd58 and 66e9bde.

⛔ Files ignored due to path filters (1)

• crates/tinymemory-module/Cargo.lock is excluded by !**/*.lock

📒 Files selected for processing (2)

• .github/workflows/ci.yml
• .github/workflows/release.yml

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[tinysweeper]

tinysweeper found nothing blocking. Approving.

             $0.0091 · 12,912 in / 1,605 out · 7,278 cached (56%) · z-ai/glm-5.2
critique:    $0.0045 · 4,698 in  / 641 out   · 960 cached (20%)   · z-ai/glm-5.2
security:    $0.0028 · 4,656 in  / 688 out   · 3,788 cached (81%) · z-ai/glm-5.2
description: $0.0018 · 3,558 in  / 276 out   · 2,530 cached (71%) · z-ai/glm-5.2