fix(bridge): gate /api/config like every other endpoint

[AltanS]

/api/config returned before calling guard(). There is no global gate in the bridge — every route
calls checkAccess/guard itself — so this was the one endpoint that bypassed both the same-origin
check and the COLLIE_PUBLIC_HOSTS allowlist.

Reproduced against a live 0.16.0 bridge, with a gated endpoint as the control:

/api/config    Origin: evil.example, Host: evil.example → 200  {"push":true,"vapidPublicKey":"BL_taz…","build":"0.16.0+9aa515f…"}
/api/snapshot  same headers                             → 403  host not allowed

Severity is low. What it exposes is the VAPID public key — handed to every browser by design —
and the build id. The bridge sends no CORS headers, so cross-origin JS can't read the response
anyway. The reason to close it is that COLLIE_PUBLIC_HOSTS exists specifically for DNS rebinding,
where the attacker's page becomes same-origin and the browser's own SOP stops helping. Every other
route is covered; this one wasn't.

No client impact, checked rather than assumed:

• The PWA only ever calls it same-origin (api.fetchConfig, web/src/lib/api.ts:304).
• Read level doesn't consult the device allowlist, so a read-only device is unaffected.
• It doubles as the connection banner's red-state liveness probe, but ConnectionBanner
  short-circuits to AuthErrorBanner on a 401/403 before the probe runs
  (web/src/components/connection-banner.tsx:46), so a refusal here can't surface as
  "bridge unreachable".

The route lives inside Bun.serve, which stays unit-untested per CLAUDE.md, so verification is the
live probe above plus its negative control — re-run post-deploy on 0.16.1.

Noted in passing by @Optic00 in #32. This does not close #32 — the substance of that issue is the
bridge-wide blast radius of snooze/prefs, which is a design decision still open.

🤖 Generated with Claude Code