cicd: add CI and CD workflow for browser extension

[pikann]

Summary

Adds CI and CD for the Chrome extension (apps/extension), plus install docs for the new distributable it produces:

• CI — extension-pr-ci.yml: on any PR touching apps/extension/**, runs npm ci, Biome lint, and tsc -b + the four Vite builds. Mirrors the existing mcp-pr-ci.yml/web-pr-ci.yml shape, adapted to npm since the extension is the only npm-based package in the repo (everything else is Bun). No test step — the extension has no test runner configured.
• CD — a build-extension job in cd.yml, modeled on the existing build-acp-bridge job (the closest analog: a locally-installed end-user artifact rather than a server image). On every published GitHub Release it builds the extension, zips dist/ into a paca-extension/ folder, and uploads paca-extension.zip to the release with a fixed name (--clobber), same convention as install.sh/docker-compose.yml, so .../releases/latest/download/paca-extension.zip is a stable link. Wired into release-assets/promote-release's needs: so a release isn't promoted to "Latest" until the extension zip has shipped too.
• Docs — apps/extension/README.md's "Setup" section is now "Install," leading with the no-build path (download the release zip → unzip → Load unpacked in Chrome); building from source is kept as a secondary/dev path. Added one row to the root README.md's documentation table, since the extension wasn't linked from anywhere before.

Not in scope here

The extension isn't on the Chrome Web Store — it needs <all_urls> host permissions to work against any self-hosted Paca instance, and no store listing or OAuth credentials exist yet (that's a manual, one-time step only the team can do in the Google console). build-extension produces exactly the artifact a future store-upload step would consume, so wiring that in later is additive.

Type of Change

• Scaffolding (CI/CD workflows)
• Documentation

Checklist

• The change is focused and scoped.
• Related documentation is updated.
• New structure or direction is explained clearly.
• I avoided unnecessary detail or premature abstraction.

🤖 Generated with Claude Code

[pullfrog]

✅ No new issues found.

Reviewed changes

• cd.yml build-extension job — new release job that installs deps, builds, zips, and uploads paca-extension.zip to the release, mirroring the build-acp-bridge job (same contents: write permission, gh release upload --clobber, node-version: 24 as the existing publish-mcp job).
• needs: wiring — build-extension added to both release-assets and promote-release dependencies in cd.yml.
• extension-pr-ci.yml — new PR CI workflow (lint + build) for apps/extension/**, structurally identical to acp-bridge-pr-ci.yml (path filter, workflow_dispatch, concurrency cancel-in-progress).
• Docs — root README docs table gains the extension README; extension README's Setup section rewritten to an Install flow (release zip, unpacked install, upgrade, build-from-source fallback), with the (see Setup) reference updated to (see Install).

I verified the change end to end: both workflow files parse as valid YAML, and on the PR head npm ci, npm run lint, and npm run build all pass, producing the dist/ contents the zip step packages. The paca-extension/ folder-prefix zip matches the README's extraction instructions, and the job placement/needs wiring follows the established build-acp-bridge/release-assets conventions. I also confirmed the extension build failure would skip release-assets (consistent with that job's "assets only for a fully shippable release" design, and the zip itself uploading independently mirrors the ACP bridge precedent). No action needed.

  ^{｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}