release: approve and publish the first verified scoped npm release

[WalksWithASwagger]

Summary

Confirm npm scope access and publish the first verified scoped release only after an explicit maintainer go-ahead.

Context

• Depends on decision(security): enforce reviewed branch protection on main #327 and package: ship a prebuilt React portal in the npm tarball #333.
• Roadmap phase: Phase 1 - release
• Relevant surface: npm registry, Git tag, and GitHub release; no implementation change is expected.
• Current behavior: package release readiness is not proven by an installed-tarball receipt tied to protected main.
• Desired behavior: one reviewed commit, tarball, npm version, tag, and GitHub release are linked with a rollback note.

Implementation Notes

• Refresh package-name availability and maintainer scope access immediately before publication because registry state can change.
• Use the exact tarball produced from the reviewed commit.
• Record an explicit approval before any publish, tag, or release mutation.
• Stop if version selection, scope access, package name, or required checks are unclear.

Acceptance Criteria

• Maintainer confirms npm scope access without exposing credentials.
• The exact tarball from the protected, reviewed commit passes installed-package smoke.
• All required checks and security gates are green.
• KK explicitly approves the exact version and npm publish --access public action.
• npm version, Git tag, and GitHub release all reference the same commit.
• Publish receipt and rollback/deprecation notes are attached without secrets.

Tests/Evals

• Re-run package boundary, installed-package smoke, deterministic verification, and security verification before approval.
• No live provider generation is part of release validation.

Verification

• npm run pack:check
• Run the installed-tarball smoke against the exact release tarball.
• npm run verify
• npm run verify:security
• Verify the published package, tag, and GitHub release resolve to the approved commit.

Agent Instructions

• Do not publish, tag, or create a release without a fresh explicit approval in the execution turn.
• Do not print registry tokens or environment values.
• Do not choose a new version silently.

Human Checkpoints

• The entire external-state mutation is maintainer-gated.
• KK must approve the package version, public access, tag, and GitHub release.

Out of Scope

• Code changes or dependency upgrades.
• Provider credentials, deployments, or generated assets.
• Legacy route retirement.
• Automatic publishing.

Linear

Not applicable. Rafiki delivery is GitHub-only; do not create or update a Linear issue.