ci: automate carpincho-wallet extension release packaging

[gabitoesmiapodo]

Summary

Closes #26

Releasing the carpincho-wallet Chrome extension was manual: a maintainer had to build locally, zip dist-extension/, and upload the asset by hand after publishing a release, letting the published artifact drift from the tagged source. This adds a CI workflow that builds and attaches the extension zip automatically on release publish, and wires the extension version to a single source of truth so the manifest, runtime, and release tag can never disagree.

Changes

• Add .github/workflows/release.yml, a generic Release workflow triggered on release: types: [published] with contents: write permission (default GITHUB_TOKEN, no PAT). Carpincho is one job (carpincho-extension) so future artifacts drop in as sibling jobs; concurrency is keyed per release tag.
• Check out and set up Node from .nvmrc with npm caching, then npm ci at the repo root with HUSKY=0.
• Make the monorepo root package.json version the single source of truth for the extension version:
  • vite.config.ts reads it and injects it via a define (__APP_VERSION__) and a build plugin that rewrites dist-extension/manifest.json version, stripping any semver prerelease/build metadata to stay Chrome-valid.
  • src/provider/status.ts reports __APP_VERSION__ instead of a hardcoded literal.
  • The node test runner mirrors the global from the same root package.json in test/setup-dom.ts.
• Gate the release on npm run lint and npm run test (reordered so the build runs before the tests that assert on its output), guard against an empty dist-extension/, zip its contents into carpincho-wallet-<version>.zip, and upload it via gh release upload "$TAG" --clobber.
• Validate that the release tag (minus v) matches the root package.json version and yields a Chrome-valid manifest version; fail the release otherwise.
• Pin all actions to commit SHAs.
• Sync docs: README "Use the extension from GitHub release source", the architecture.md project tree (.github/workflows/), and carpincho-wallet/AGENTS.md (version source-of-truth rule).

Acceptance criteria

• Workflow at .github/workflows/ triggers on release: types: [published].
• Job has permissions: contents: write for asset upload via default GITHUB_TOKEN.
• Uses actions/checkout@v4 and actions/setup-node@v4 with node-version-file: .nvmrc and npm caching.
• Installs deps with npm ci and HUSKY=0.
• Builds via npm --prefix carpincho-wallet run build:extension.
• Zips the contents of dist-extension/ into carpincho-wallet-<tag>.zip.
• Uploads the zip to the triggering release using github.event.release.tag_name.
• The build sets the manifest version from the release (manifest no longer hard-codes a version).

Note: the manifest version is now sourced from the root package.json (which CI asserts equals the release tag) and injected at build time, rather than rewritten directly from the tag as the issue originally specified -- this gives one committed source of truth for manifest, runtime, and tag. Other adaptations to the npm-workspaces layout: npm ci and the cache key target the root package-lock.json. Beyond the listed criteria: the workflow was generalized to a repo-wide Release pipeline, the lint/test gate is included, and version validation, an empty-build guard, and pinned action SHAs were added.

Test plan

Automated tests

npm --prefix carpincho-wallet run test (run in CI after the build). Adds a test asserting the built dist-extension/manifest.json version derives from the root package.json (sanitized). Verified locally: 226 tests pass, lint clean. A temporary root bump to 9.8.7-rc.2 produced manifest 9.8.7 and runtime 9.8.7-rc.2, then was reverted.

Manual verification

• Publish a GitHub release whose tag matches the root package.json version (e.g. v0.1.0) and confirm a carpincho-wallet-0.1.0.zip asset is attached.
• Confirm the zipped manifest.json version matches the tag.
• Publish a release whose tag does not match package.json, or is not Chrome-valid, and confirm the workflow fails at the validation step.

Breaking changes

None.

Checklist

• Self-reviewed my own diff
• Tests added or updated
• Docs updated (if applicable)
• No unrelated changes bundled in

Screenshots

None.