feat(relay): rendezvous-relay service — 7 packages + plans (contracts/transport/agent/control-plane/e2e/auth/web)

Multi-tenant reverse-tunnel service ("ngrok for Claude Code" with E2E): a
host-agent dials OUT to an operator-run relay; external devices reach the host
THROUGH the relay, routed by per-tenant subdomain, forwarding ciphertext only
(the relay never sees plaintext). Lets a customer reach their own self-hosted
web-terminal from anywhere with zero networking setup.

Packages — all tsc-strict + vitest green (656 tests), cross-package integration verified:
- relay-contracts: frozen shared contracts (mux frame codec, data model,
  capability token, E2E envelope, pairing) — the src/types.ts analog
- term-relay:   native WS mux + stateless data plane (subdomain routing, ciphertext forward)
- agent:        host-agent (pairing, per-host Ed25519 + mTLS dial-out, forwards to 127.0.0.1:3000)
- control-plane: accounts/hosts registry, pairing-code flow, routing table, provisioning
- relay-e2e:    browser<->agent E2E (X25519 ECDH through relay, AEAD, anti-replay, recoverable replay key)
- relay-auth:   Passkey/WebAuthn, capability tokens, per-host certs, deny-by-default tenant isolation
- relay-web:    browser login + Web Crypto E2E + client-side preview rendering

Security invariants INV1-15 enforced; cross-tenant isolation CI tripwire live
(.github/workflows/relay-tripwire.yml). Design + implementation-level plans in
docs/PLAN_RELAY_*.md and docs/EXPLORE_RELAY_SERVICE.md.

NOTE: generated autonomously per the reviewed plans. The security-critical
packages (relay-e2e, relay-auth) REQUIRE expert security audit before any real
deployment — passing tests prove self-consistency, not resistance to attackers.
Base app (src/, public/) unchanged; concurrent desktop work left uncommitted.

control-plane/src/db/pool.ts

@@ -0,0 +1,31 @@
+/**
+ * T2 — Postgres pool + typed `query` wrapper. PARAMETERIZED ONLY: the wrapper accepts
+ * `(sql, params)` and passes params to the driver separately — there is NO string-interpolation
+ * path, so SQL injection via value concatenation is structurally impossible (INV5-adjacent, §7).
+ *
+ * The client is injected (`Queryable`) so the wrapper is unit-testable without a live DB; the real
+ * `pg.Pool` is constructed by `createPgPool`. Applying the migrations + mapping the repository ports
+ * to SQL over this wrapper is the Testcontainers integration seam (PLAN §10).
+ */
+import pg from 'pg'
+
+/** Minimal driver surface the wrapper needs — satisfied by `pg.Pool` and `pg.PoolClient`. */
+export interface Queryable {
+  query(text: string, params: readonly unknown[]): Promise<{ rows: unknown[] }>
+}
+
+export type QueryFn = <T>(sql: string, params: readonly unknown[]) => Promise<readonly T[]>
+
+/** Build a parameterized-only query function over any `Queryable`. */
+export function createQuery(client: Queryable): QueryFn {
+  return async <T>(sql: string, params: readonly unknown[]): Promise<readonly T[]> => {
+    // Params ALWAYS travel separately from the SQL text — never interpolated into it.
+    const result = await client.query(sql, params)
+    return result.rows as T[]
+  }
+}
+
+/** Construct a real Postgres connection pool (production). */
+export function createPgPool(connectionString: string): pg.Pool & Queryable {
+  return new pg.Pool({ connectionString })
+}