feat(gateway): enforce cert-identity ↔ agent-token tenant binding (Phase 5)

[marcorivm]

Phase 5 (final) of remote-gateway hardening — cert↔token tenant binding enforcement

Stacked on #4 (Phase 3) — base is phase3/relay-mode. Review/merge #2 → #3 → #4 first; this diff shows only Phase 5.

What this PR does

Turns the mTLS certificate identity — extracted and logged since Phase 1 — into an enforced access-control boundary. A relay's client certificate may only carry agent tokens for its own tenant (PROJECT-scoped). This is the payoff of the whole series: the gateway now verifies not just that a caller holds a valid cert, but that the cert's identity is permitted to carry this specific agent's token.

The rule

Permitted iff the ClientHost resolved from the cert's spiffe://onecli/host/<id> identity has projectId == token.project_id (+ org consistency when the host's org is non-null, + the host is not revoked). The ClientHost row is the allowlist entry — deny-unless-a-matching-non-revoked-row.

Rollout (safe by construction)

GATEWAY_BINDING_ENFORCEMENT = off | log | enforce, default off — unset is byte-identical to today with zero per-request cost. Operators roll out off → log (records every would-deny as a structured audit event without blocking, revealing the real host↔project topology) → enforce.

Security / correctness properties

• Both proxy paths enforce. One shared enforce_binding helper is called from handle_connect AND handle_http_proxy, each after tenant resolution and before any upstream path — the absolute-form route is not a bypass.
• on_mtls is a separate signal, threaded from the accept loop (true for the mTLS listener, false for plain) — NOT inferred from whether the cert identity parsed. So an mTLS cert with an unparseable identity is denied in enforce (can't satisfy the allowlist), while the plain listener (the web-app/loopback path with no cert) is exempt by listener kind in every mode.
• Fail-closed. A DB/cache lookup error in enforce denies (502, retryable) — never allows. Permanent verdicts (mismatch / unknown host / revoked / missing identity) return 403. Justified: token resolution already 502s on any DB error before the binding read, so fail-closed adds ~no new availability loss.
• Untrusted identity at the DB layer — parameterized $1 lookup on the unique spiffe_uri column, no interpolation.
• No secret leakage — the 403 body is {"error":"identity_not_permitted"}; audit logs carry spiffe/host-project/token-project/org/agent-id/decision, never the token.
• Honors ClientHost.revokedAt as an immediate application-layer soft-revoke (within one 60s cache TTL) — an app-layer revoke lever even without CRLs.

Testing

682 tests (cargo test), clippy --all-targets -- -D warnings + fmt clean. Exhaustive unit coverage of the decision table and every deny branch; enforce_binding off/exempt/match/mismatch/revoked/unparseable-identity/DB-error paths; the 502-vs-403 split; off-mode zero-lookup (proven against a dead pool). cargo build --features cloud unchanged (27 pre-existing ee/*.rs errors, none from this change).

Notes for reviewers / follow-ups (out of scope here)

• No live-DB test tier exists in the gateway crate, so the sqlx wire-decode of a non-null revoked_at isn't exercised end-to-end (the decision logic and cache round-trip are). A review caught and fixed a real type bug here: revoked_at is TIMESTAMP (no tz) → time::PrimitiveDateTime, not OffsetDateTime — otherwise a revoked host would have failed to decode and denied via the wrong (502) path.
• A ClientHost.revokedAt writer (API/UI) is still needed to use the revoke lever.
• Enforcement is only meaningful if the plaintext listener is restricted to loopback/trusted network — the gateway warns at startup when enforce is on and the plain listener is bound to a non-loopback address.

Pipeline: Opus plan → Sonnet dev → Opus security review (no blockers; caught the revoked_at type bug + broadened the bypass warning) → fixes → Sonnet QA (GO).

https://claude.ai/code/session_01BgJuqEJqf7ZiUdqHWxi6bt