ci: verify formatting, types, build, and tests on every PR

[galatanovidiu]

Adds .github/workflows/ci.yml. Until now release.yml was the only workflow and it fires on release: published, so nothing has ever run on a pull request.

Why this is the gap that matters

Every problem found this week traces back to it:

• Prettier had drifted across 35 tracked files
• npm run check had never once been executed — a bare tsc in it was silently overwriting the tsup bundle with per-file output (fix(tooling): stop npm run check from overwriting the build #98)
• npx jest tests/unit/ was labelled "run all tests" while skipping three integration suites
• PRs chore(deps): bump hono from 4.12.26 to 4.12.31 #94 and chore(deps): bump fast-uri from 3.1.2 to 3.1.4 #95 were merged reporting no checks reported

A pre-commit hook cannot close this. Dependabot commits are created server-side by GitHub and never execute local git hooks, and any contributor can pass --no-verify. CI is the only enforcement that covers bots and strangers.

What runs

npm ci → npm run check → npm run build → both jest suites → version-constant guard.

The version guard is the one addition beyond "check + tests". AGENTS.md states the rule that package.json and MCP_WORDPRESS_REMOTE_VERSION must move together; drift has already shipped a token directory named wordpress-remote-undefined. A rule a check can enforce belongs in the check. Happy to drop it if you would rather keep this PR to exactly formatting/types/build/tests.

Security posture

• pull_request, not pull_request_target — fork PRs get a read-only token and no secrets
• permissions: contents: read
• No github.event.* value is interpolated into any run: block; the only expression is a concurrency group name, which is never shell-evaluated

Verified locally

Every step was run on this branch before pushing: check passes, build passes, 15 suites / 225 tests pass. The version guard was tested in both directions — it passes on matching versions and correctly fails on a simulated 0.4.0 vs 9.9.9 drift.

This does not block merging on its own

The protect trunk ruleset currently has deletion, non_fast_forward, and pull_request with required_approving_review_count: 0. There is no required_status_checks rule, so this workflow will report but not gate.

Making it blocking is a separate ruleset change, and it has to happen after this merges — adding a required check named verify while no workflow produces it would leave every PR waiting forever on a check that never runs.