feat(server): carry re-pair guidance on a typed scope error

[chrischall]

Closes #195.

The problem

Gate #2 refuses a request whenever an MCP widens its declared scope, until the user re-approves. #187 taught the CLI to explain that — but MCPs don't go through the CLI. They consume the bridge via @fetchproxy/bootstrap, catch failures, and re-wrap them in their own copy, so the remedy never survived:

SignUpGenius auth: no SIGNUPGENIUS_USER_KEY or SIGNUPGENIUS_EMAIL/PASSWORD set,
and fetchproxy lift failed: cookie keys not in declared set: refreshToken

Structurally accurate and useless — it names the symptom, points at auth config that isn't the problem, and omits the one action that fixes it. This is a routine event: signupgenius-mcp widened its scope twice in one afternoon.

The fix

FetchproxyScopeError carries the guidance on .hint, mirroring FetchproxyBridgeDownError — a shape consumers already surface verbatim, so adopting it needs no new habit:

SignUpGenius auth: fetchproxy lift failed: cookie keys not in declared set: refreshToken.
the declared scope changed since you paired, so the extension is refusing the request.
Revoke this MCP in the Transporter extension popup, then re-run — you will be asked to
approve the new scope. This is not a version problem and does not need an update.

It extends FetchproxyProtocolError, so every existing catch site and classifyBridgeError() keep working unchanged.

Two things done deliberately

All eight sites that turn an extension ok:false into a throw now route through protocolErrorFrom(). Typing it at one site and leaving seven others would recreate the same partial-coverage bug in a new place.

The factory matches not in declared rather than enumerating the nine wordings — enumerating them is exactly how the first cut of the CLI fix missed five (#188).

The CLI drops its own regex and reads the typed error: the same knowledge in one place instead of two copies free to drift.

Verification

1105 tests, typecheck and build clean. The CLI tests now construct errors via protocolErrorFrom() — the way the server actually builds them — rather than hand-rolling a FetchproxyProtocolError that no longer represents the real path.

[claude]

Claude finished @chrischall's task in 3m 25s —— View job

---

Review complete ✅

• Read CLAUDE.md conventions
• Read PR diff
• Review packages/server/src/ws-server.ts changes (typed scope error, protocolErrorFrom())
• Review packages/cli/src/bridge-errors.ts changes (regex removal)
• Review test coverage
• Post findings and verdict

Summary: Clean, well-scoped fix. FetchproxyScopeError mirrors FetchproxyBridgeDownError's existing .hint shape exactly, protocolErrorFrom() is genuinely applied at all 8 sites that turn an extension ok:false into a throw (verified by grep — the remaining new FetchproxyProtocolError(...) calls are for unrelated failure modes: malformed-response-shape errors, rejectAllPending, and the pair-pending guard, none of which are extension scope rejections), and the regex (/not in declared/) matches all nine real wire-format rejection strings emitted by extension-core/src/background.ts (verified against the actual source, not just the test fixtures). The CLI now reads the typed error instead of re-deriving its own copy of the guidance text, which is exactly the stated goal. Tests cover the new factory, the CLI consumption path, and confirm classifyBridgeError still buckets it under 'protocol' for back-compat.

One pre-existing (not introduced by this PR, not blocking) observation: extension-core/background.ts:1367,1466 also rejects with capability "X" not granted (declared: [...]) when an MCP widens its capability set (not a key/bucket) — per CLAUDE.md, "Tightening (or widening) the capability set forces a re-pair," so this is the same class of gate-#2 event, but its wording doesn't contain "not in declared" and so falls through to the generic "version mismatch" hint rather than getting FetchproxyScopeError. This gap predates this PR (the CLI's old regex had the identical blind spot), so it's out of scope here, but worth a future follow-up if capability-widening errors are ever seen in the wild.

No 🔴 Important or 🟡 Nit findings against the diff itself.

Verdict: pass

[github-actions]

✅ Auto-review verdict: pass — Well-scoped, correctly implemented typed-error fix: FetchproxyScopeError mirrors the existing FetchproxyBridgeDownError.hint shape, protocolErrorFrom() is applied at all 8 relevant sites, and the matching regex covers all nine real extension rejection wordings. No blocking issues.