chore: sync Cargo.lock version in release.sh + catch up 0.13.0

release.sh was bumping Cargo.toml and pyproject.toml but never touching
Cargo.lock, so every release left the committed lockfile one version
behind (e.g. after v0.13.0, Cargo.lock still listed pg0 as 0.12.3).
The release CI was rewriting it during build, but that contradicts the
"commit Cargo.lock for reproducible builds" policy from 28c51ec.

Add `cargo update -p pg0 --offline` to the release script between the
Cargo.toml bump and the pyproject.toml bump. --offline keeps the
operation hermetic (no network, no build.rs) and only touches the pg0
entry in the lockfile. Also stage Cargo.lock in the resulting commit.

Also include the one-line Cargo.lock fix-up for 0.13.0 so main is no
longer out of sync.

Author: nicoloboschi

Cargo.lock

@@ -118,13 +118,18 @@ release_cli() {
     sed -i.bak "s/^version = \".*\"/version = \"$version\"/" Cargo.toml
     rm -f Cargo.toml.bak
 
+    # Sync Cargo.lock so the committed lockfile matches Cargo.toml.
+    # --offline avoids network and skips build.rs entirely.
+    echo "Syncing Cargo.lock to $version..."
+    cargo update -p pg0 --offline
+
     # Update version in pyproject.toml
     echo "Updating pyproject.toml version to $version..."
     sed -i.bak "s/^version = \".*\"/version = \"$version\"/" sdk/python/pyproject.toml
     rm -f sdk/python/pyproject.toml.bak
 
     # Commit and tag
-    git add Cargo.toml sdk/python/pyproject.toml
+    git add Cargo.toml Cargo.lock sdk/python/pyproject.toml
     git commit -m "chore: bump CLI version to $version"
     git tag -a "$tag" -m "Release $version"