ci: add GitHub Actions workflow for bun and pnpm verification

[Alex979]

Adds the repo's first CI workflow: two parallel jobs that both run typecheck, tests, and a production build.

Jobs

• Bun — bun ci (frozen lockfile install), then typecheck / test / build. The primary gate.
• pnpm — pnpm install --frozen-lockfile, then the same three commands through pnpm. Mirrors how PluginDatabase installs and builds plugins, so a stale or divergent pnpm-lock.yaml fails here before it reaches a release or the plugin database PR.

Notes

• Both jobs run on ubuntu-latest; Bun is installed in the pnpm job too because the test script is bun test.
• pnpm is pinned to v10, which natively writes this repo's lockfileVersion: 9.0 format. PluginDatabase itself uses unpinned latest pnpm; if that ever matters we can revisit.
• Frozen installs catch each lockfile drifting out of sync with package.json. Cross-lockfile divergence (both fresh but resolving differently) is intentionally not checked yet.
• Triggers on pushes to main and all pull requests; superseded runs are cancelled via a concurrency group.

Testing

• YAML validated locally; all four bun-side steps were run manually earlier today (typecheck ✅, 35/35 tests ✅, prod build ✅).
• The pnpm path has no local pnpm install available, so CI is its first exercise — if it goes red, the logs will say why.

[Alex979]

Addressed review findings #2 and #4:

• ci: only cancel superseded pull request runs — concurrency cancellation is now conditional (github.event_name == 'pull_request'), so back-to-back merges can no longer cancel each other's post-merge validation runs.
• test: guard manifest version sync on every test run — added a meta-test that runs readReleaseVersion against the real repository root, enforcing package.json/plugin.json sync in CI instead of only at release time.

#1 (pinning Bun) and #3 (Node pin/caching) intentionally skipped: #1 is a float-vs-pin trade-off with a benign, visible failure mode, and #3 was self-rated as not worth it at this job duration.