Avoid release workflow failure on npm publish auth

[Sungblab]

Summary

• stop the tag release workflow from attempting CI npm publish when npm Trusted Publishing is not configured
• make the workflow verify an already-published npm version and create the GitHub Release only when present
• update release docs to publish npm locally before pushing the tag

Verification

• npm run docs:check
• npm test

[gemini-code-assist]

Code Review

This pull request updates the release documentation in docs/release.md to transition from a CI-driven npm publishing model to a local npm publishing workflow, followed by a tag-driven GitHub Actions workflow for verification and release creation. The feedback suggests a safer ordering of commands in the documentation: pushing the release commit to the remote main branch before executing npm publish to prevent scenarios where a package is published but the corresponding source code fails to push.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

It is safer to push the release commit to the remote main branch before publishing the package to npm. If the push to main fails (for example, due to branch protection rules, hooks, or concurrent changes), you avoid a scenario where the package version is already live on npm but the corresponding source code is not yet pushed to the remote repository.

Suggested change

	npm run publish:check
	npm publish --access public
	git push origin main
	git tag v0.1.4
	git push origin v0.1.4
	git push origin main
	npm run publish:check
	npm publish --access public
	git tag v0.1.4
	git push origin v0.1.4