chore(release): include hyperdb-compile-check in lockfile-sync guard allow-list

[StefanSteiner]

Summary

Unblocks the v0.4.0 release (again). After the version-pin marker fix (#97), the
release-please workflow got past dependency resolution and ran its Cargo.lock
sync — but then the "Verify lockfile diff is workspace-only" sentinel aborted
the run with:

Error: Cargo.lock sync touched non-workspace packages: hyperdb-compile-check

The lockfile change itself is correct — this is a false positive in the
guard.

Root cause

The sentinel builds its allow-list of legitimate-to-change packages from
cargo metadata --no-deps on the root workspace:

WORKSPACE=$(cargo metadata --no-deps --format-version=1 \
  | jq -r '.packages[] | select(.source==null) | .name' | sort -u)

But hyperdb-compile-check is deliberately not a member of the root
workspace — it declares its own [workspace] so it can be built and tested
standalone. So root cargo metadata omits it. It is, however, a path crate in
the root lockfile, so the release lock-sync correctly bumps its version row
0.3.1 → 0.4.0 along with the other 8 workspace crates. The guard sees a
changed package not in its (incomplete) allow-list and aborts.

This is the same hyperdb-compile-check-is-a-separate-workspace exception that
needed handling for the version-pin markers (#97) and for publish ordering —
the lockfile guard is the third spot it was missed.

Fix

Union the root workspace members with hyperdb-compile-check's own
workspace members:

WORKSPACE=$( { \
    cargo metadata --no-deps --format-version=1; \
    cargo metadata --no-deps --format-version=1 \
      --manifest-path hyperdb-compile-check/Cargo.toml; \
  } \
  | jq -r '.packages[] | select(.source==null) | .name' | sort -u)

Both halves stay runtime-derived, so future workspace additions/renames stay in
sync automatically — no hard-coded list to maintain (the property the original
guard was designed for). Also corrects the adjacent comment that claimed "8
workspace-member version rows" to 9, naming hyperdb-compile-check.

Verification

Reproduced the exact failure locally against the real v0.4.0 release-please
branch lock diff (all 9 path crates bumped 0.3.1 → 0.4.0):

• Old allow-list (root only): flags hyperdb-compile-check as unexpected →
  abort (matches the CI failure).
• New allow-list (root ∪ compile-check): zero unexpected packages → guard
  passes.

YAML validated. No behavior change beyond the allow-list union; the format-version
layer-1 check and the rest of the sentinel are untouched.

After this merges

release-please re-runs on push to main, re-syncs Cargo.lock on the release
branch, and the guard now passes → the lockfile-sync commit lands on the release
PR automatically. Then merge the release PR, move/recreate the v0.4.0 tag onto
the release commit, and re-run the release. (Nothing has been published to
crates.io yet — the release.yml version gate has been aborting cleanly.)