fix: self-heal Cargo.lock in Release instead of depending on release-please

[mulhamna]

Summary

• PR fix: let release-please manage Cargo.lock's version entry #41's /Cargo.lock extra-file (JSONPath-filtered TOML update) doesn't actually work: PR chore(main): release 0.11.2 #43's latest release-please run logged ⚠ No entries modified in $.package[?(@.name=="forgeguard")].version, despite that exact filter matching cleanly against a plain TOML parse locally. Their internal TOML handling isn't behaving the way I assumed from reading the updater source — reverting that config since a non-functional silent no-op is worse than not having it.
• Root problem stands: any tag release-please creates is immutable, and Cargo.lock never gets synced in that same commit. Chasing "make release-please produce a correct commit" has failed twice now (fix: repair release-please pipeline and enable npm publish #35 pattern repeating, fix: let release-please manage Cargo.lock's version entry #41 not working). Flipping the fix to the consumer (Release itself) instead of the producer (release-please) removes the dependency entirely.

Changes

• .github/workflows/release.yml: both verify and each build matrix job now run cargo update -p forgeguard --precise <tag-version> right after the toolchain is installed, before anything --locked. This touches only the forgeguard workspace member's own lock entry — verified locally, not guessed.
• release-please-config.json: reverted the non-functional /Cargo.lock extra-file from fix: let release-please manage Cargo.lock's version entry #41.

Verified locally before pushing (per your ask not to keep guessing)

1. Bumped crates/forgeguard-cli/Cargo.toml to 0.11.2 without touching Cargo.lock — reproduced the exact CI failure (cargo build --locked → "cannot update the lock file").
2. Ran cargo update -p forgeguard --precise 0.11.2 — diff showed exactly one line changed (forgeguard's version), cargo itself reported "9 unchanged dependencies".
3. Re-ran cargo build --locked --release -p forgeguard — succeeded.
4. Ran the same --precise command with the version already current — no-op, exit 0, no diff (safe to always run unconditionally).
5. Reverted the local test changes before committing anything.

Sequencing

This needs to merge before PR #43 (chore(main): release 0.11.2) merges, so the chained Release job picks up the self-heal step from main's latest release.yml when it runs. PR #43's tagged commit will still carry a stale Cargo.lock either way (unavoidable, same as #41 not fixing that at the source) — this fix means that no longer matters.

Test plan

• Reproduced the failure and verified the fix locally, described above
• Both changed files validated as well-formed YAML/JSON
• After merging this + PR chore(main): release 0.11.2 #43, confirm Release's build matrix jobs all succeed (not just verify) and all assets upload
• Confirm npm-publish fires and @suiflex/forgeguard@0.11.2 publishes