fix: guard release.sh against a Cargo.toml/tag version mismatch

[arjun2075]

Fixes #49

Root cause

release.sh takes a version tag as its only argument but never checks it against Cargo.toml's [workspace.package] version before building. clap derives --version from CARGO_PKG_VERSION at compile time (crates/infigraph-cli/src/main.rs:49), so a release cut without first bumping Cargo.toml ships a binary whose --version output silently lags the release tag it was built for.

Confirmed via git log -p -- Cargo.toml: the last version bump before the reported bug was 3.2.5 → 3.2.6. No commit ever bumped it to 3.2.7 or 3.2.8 — the next bump on record is 3.2.9. So both v3.2.7 and v3.2.8 were built and tagged with the stale 3.2.6 baked in, which also explains why v3.2.6 and v3.2.8 share an identical aarch64-apple-darwin binary hash (no version-relevant recompile happened between them on that platform).

Fix

Add a check right after argument parsing in release.sh: extract the workspace version from Cargo.toml and fail loudly if it doesn't match the requested release tag ($VERSION), before any build/upload work happens.

$ ./release.sh v3.2.8   # Cargo.toml still says 3.2.6
error: release tag is v3.2.8 (3.2.8) but Cargo.toml [workspace.package] version is 3.2.6.
Bump the workspace version in Cargo.toml to 3.2.8 and commit it before releasing.

Testing

release.sh isn't part of the cargo test suite (it's an ops script), so I verified it directly:

• bash -n release.sh — syntax check passes
• Ran the version-extraction + comparison logic standalone against the real Cargo.toml (currently 3.2.9) — matches correctly, and correctly rejects a mismatched tag
• Reproduced the historical bug scenario (Cargo.toml=3.2.6, tag=v3.2.8) — the guard fires with the exact error above, confirming it would have caught infigraph --version reports 3.2.6 in both v3.2.7 and v3.2.8 release binaries #49 before either broken release shipped

I didn't attempt to auto-bump Cargo.toml from the script — that's a bigger behavior change (deciding whether the script should also commit a version bump) that seemed worth a separate discussion; this PR just stops the bad release from happening silently.