Automate Chrome Web Store publishing via GitHub Actions (closes #32)

[Cyclodex]

Summary

Adds the CI-driven release path described in #32 and the spec at docs/superpowers/specs/2026-05-13-cws-publishing-automation-design.md.

On every push to main, release-please maintains an auto-updating "Release PR" with version bump + changelog + manifest sync. Merging that Release PR creates the tag + GitHub Release, which fires publish-chrome-web-store.yml — builds via pwsh -File Build.ps1 -CreatePackage, uploads + publishes to the CWS API via mnao305/chrome-extension-upload@v5, and attaches the zip to the GitHub Release.

The existing createRelease.ps1 / Build.ps1 / updateManifest.js are preserved unchanged as a manual fallback path.

What's in it

• release-please-config.json + .release-please-manifest.json (seeded with 1.3.5, the current main version).
• .github/workflows/release-please.yml — orchestrator.
• .github/workflows/publish-chrome-web-store.yml — CWS uploader (triggered on release.published; also workflow_dispatch for smoke tests / manual re-runs).
• docs/architecture/publishing.md — canonical doc covering both paths, conventional-commit rules, the Release-PR walkthrough, one-time setup, and recovery procedures.
• RELEASE.md reframed with the automatic path as default and the manual content preserved.

Deferred (depend on PR #31 landing first)

• CLAUDE.md one-line cross-link to publishing.md.
• docs/architecture/build-and-release.md cross-link paragraph.

Both files only exist on the test-harness branch (#31), not on main. Once #31 merges, a tiny follow-up commit (or a quick rebase of this PR onto the post-merge main) adds the two cross-links.

Test Plan / how to review

• Read the spec at docs/superpowers/specs/2026-05-13-cws-publishing-automation-design.md if you want the design rationale; the issue Automate Chrome Web Store publishing via GitHub Actions #32 summary is shorter.
• Confirm no source code in packages/** or in the PowerShell scripts was touched: git diff main...HEAD -- packages createRelease.ps1 Build.ps1 updateManifest.js should be empty.
• Spot-check release-please-config.json and .release-please-manifest.json parse: node -e "JSON.parse(require('fs').readFileSync('release-please-config.json','utf8')); JSON.parse(require('fs').readFileSync('.release-please-manifest.json','utf8')); console.log('OK')".
• Read docs/architecture/publishing.md for the Release-PR concept and conventional-commit rules.

Smoke test (operator: @FabianGander — before/after merge)

Before relying on the auto-trigger:

1. Configure the four GitHub Actions secrets per docs/architecture/publishing.md → "One-time setup".
2. Actions tab → publish-chrome-web-store → "Run workflow" → tag 1.3.5, publish: false.
3. Verify the resulting draft appears in the Chrome Web Store dev console.
4. Discard the draft, or publish it manually.

After that, the next conventional-commit merge to main will produce a Release PR; merging the Release PR will publish for real.

Out of scope (follow-up specs)

• "Beta" listing / staged-rollout pattern.
• Dependabot triage on main.
• Commit-message linter (commitlint).
• Auto-publishing on local-script-pushed tags (currently only the CI path auto-publishes).

Closes #32.