[gmemmy]

Problem

The release-ready changes are now merged, but the package manifest still identifies the package as 0.1.21. Private candidate identities 0.1.19 through 0.1.22 were already used and must not be reused for different bytes, so the next candidate needs a unique version.

What changed

• Set the package version to 0.1.23.
• No runtime, schema, API, documentation, lockfile, or dependency behavior changed.

Why this approach

Using the next unused candidate identity preserves immutable package provenance. Reusing an earlier private candidate version would make downstream evidence ambiguous even though those versions were never published to npm.

Proof

• pnpm install --frozen-lockfile --offline passed.
• pnpm release:check passed on the exact candidate tree, including the full test suite, package smoke, and installed-consumer rehearsal.
• git diff --check origin/main...HEAD passed.
• Independent bounded review returned CLEAN with no P0-P3 findings.
• Live npm inventory currently ends at 0.1.18; 0.1.23 is unused.

Runtime/device proof: Not run. This PR changes package identity only.

Publication proof: Not applicable. No npm publish, tag, or GitHub Release occurred.

Risks and limits

• This PR prepares a candidate identity; it does not publish or release it.
• Downstream runtime and evidence acceptance remain separate gates.

Stack/review order

• Base: main at b26e1ed754d6f0483c59010e8a3a9720df5a1453.
• Review this as a version-only release candidate after the merged evidence and lifecycle stack.

Follow-ups

• Pack and record immutable tarball identity after this exact commit passes CI.
• Keep merge, npm publication, tag creation, and GitHub Release as separate approvals.