fix(clients): resolve Node client lock platform entries

[jeremi]

What broke

npm ci fails on pristine main for all three Node clients:

npm error `npm ci` can only install packages when your package.json and
package-lock.json are in sync ... lock file's
@registrystack/evidence-client-darwin-arm64@ does not satisfy
@registrystack/evidence-client-darwin-arm64@0.23.0

This blocks Native client bindings and both Release Linux Node clients
jobs on every PR that touches paths triggering them, including #792.

It is not only a CI annoyance. release-candidate.yml runs npm ci too, in
the Build Node client packages step:

client_dir="${GITHUB_WORKSPACE}/crates/registry-${client}-client-node"
(cd "${client_dir}" && npm ci)

so re-running the v0.23.0 candidate today fails at that step.

Why

The three lockfiles carry their platform binding packages as bare stubs:

"node_modules/@registrystack/evidence-client-darwin-arm64": { "optional": true }

with no version, resolved, or integrity. npm accepts a stub like that
only while the version declared in package.json is unpublished. v0.23.0
published at 07:43Z today, and npm ci has failed since.

The stubs were written by 89358a219 chore(release): prepare v0.23.0 beta-34,
which regenerated the locks while @registrystack/*-client-*@0.23.0 did not
yet exist on the registry. de1fd31e2 did exactly the same for v0.22.0, and
9200b8403 happened to restore the resolved entries afterwards, so the cycle
completed by accident last time rather than by design.

That is the shape of the recurrence: main is broken from the moment a
release publishes until something regenerates the locks. Release prep itself
hides the breakage, because the version it pins is unpublished again.

The change

Regenerated with npm install --package-lock-only --ignore-scripts in each of
the three client directories, now that 0.23.0 is published. Nine entries gain
their version, resolved, integrity, cpu, os, libc, license, and
engines fields back. No other dependency in any of the three locks moves:
the diff is +144/-9 and every hunk is one of those nine entries.

Review notes (release provenance)

The change adds integrity hashes that bind these locks to published artifacts,
so the hashes were verified against the registry rather than trusted from the
local npm cache. All nine match the registry's dist.integrity for 0.23.0:

MATCH @registrystack/discovery-client-{darwin-arm64,linux-arm64-gnu,linux-x64-gnu}
MATCH @registrystack/evidence-client-{darwin-arm64,linux-arm64-gnu,linux-x64-gnu}
MATCH @registrystack/relay-client-{darwin-arm64,linux-arm64-gnu,linux-x64-gnu}

No release artifact, manifest, or signed material is touched.

Verification

npm ci && npm run build:debug && npm test && npm run check:types && cmp ../../LICENSE LICENSE,
which is the Native client bindings job body, run locally against all three
clients. All three pass.

Follow-up worth deciding separately

This is structural. The checked-in package.json pins optionalDependencies
to the exact release version, so between prep and publish the lockfile
cannot be complete, and after publish it must be regenerated to stay
valid. validate_client_package_versions in release/scripts/registry-release
checks only the two root identities, so a lock full of stubs passes release
validation either way.

Options, none applied here:

1. Make post-publish lock regeneration an explicit step in the release
   runbook, which is what this PR does by hand. Keeps the contradiction but
   makes the repair deterministic instead of incidental.
2. Drop optionalDependencies from the checked-in manifests and let napi-rs
   inject them at publish time, so the checked-in lock never references an
   unpublished version. This is the only option that removes the contradiction
   rather than scheduling around it.
3. Have the release tooling reject stub platform entries. On its own this
   cannot work, since the stub is unavoidable at prep time; it is only
   coherent as a post-publish check paired with option 1.

I did not pick one. It changes the release contract and recurs every cycle.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 41bd5f13b3

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".