[Ticket]: Spike - service-to-service identity: enable Cilium mutual auth (SPIFFE) or install Istio?

### Type

Spike / Investigation

### Summary

Decide how service-to-service identity and encryption work in this cluster: **enable Cilium's
SPIFFE-based mutual authentication**, or **install Istio**. Cilium is already the CNI and
already ships the capability, disabled. Istio is not installed anywhere and would be a fourth
data plane.

### Intent

Static shared secrets are the estate's default for service-to-service auth — Authorino carries
**21 `apiKey:` identity blocks against 2 `jwt:`**, and `lightbridge-governance` authenticates
its ingest route with a single shared `X-Internal-Token`. Replacing those one at a time
without deciding the underlying model means twenty-two separate decisions, each made by
whoever touches it.

Two distinct problems are being conflated and should be separated by this spike:

1. **Workload identity for in-cluster callers** — largely solved already; see Out of Scope.
2. **Transport-level identity and encryption between services** — not solved, and the subject
of this ticket.

### Source of truth (links)

- Verified against `hetzner-prod`, 2026-08-27 (below)
- `lightbridge-governance`#169 — the ServiceAccount-token path for pollers
- `lightbridge-governance` RFC-0003 §4 pattern D — "in-cluster, authenticated by topology only"
- ai-helm — no `istio`, `spiffe`, `spire` or `linkerd` reference in any chart

### Current Behavior

```
cilium v1.19.4 CNI, deployed
mesh-auth-enabled false SPIFFE mutual auth AVAILABLE, switched off
enable-l7-proxy true
encryption none no ipsec, no wireguard
istio / spire / linkerd ABSENT — not in ai-helm, not in the cluster
authorino deployed 21 apiKey: blocks vs 2 jwt:
data planes today Envoy Gateway · Envoy AI Gateway · Cilium · Traefik
```

There is **no pod-to-pod encryption** in this cluster today, and no cryptographic service
identity. Trust between services is topological: ClusterIP plus `CiliumNetworkPolicy`.

### Expected Behavior

A recorded decision, with the rejected option and its reason, covering: what identity a
service presents, whether traffic is encrypted, and which mechanism enforces it.

### Acceptance Criteria

1. A decision between the two options below, recorded as an ADR.
2. The decision states plainly **whether traffic is encrypted**, since that is a separate
question from identity and neither option answers both by default.
3. A migration path for the 21 `apiKey:` AuthConfigs — or an explicit statement that they are
out of scope and why.
4. If Istio: an answer for how it coexists with Envoy Gateway and Envoy AI Gateway, which
already own north-south traffic.
5. If Cilium: confirmation that its mutual-auth model is sufficient for the actual threat —
see Risks.

### Out of Scope

- **In-cluster polling callers.** That is `lightbridge-governance`#169 and is solvable today
with projected ServiceAccount tokens plus Authorino TokenReview — no mesh required. Do not
block that on this decision.
- External callers (laptops, CI runners), which need `lightbridge-authz`#534.
- Retiring the 21 `apiKey:` blocks, beyond deciding whether this decision governs them.

### Technical Context

**Option A — enable Cilium mutual authentication.** Cilium 1.19.4 supports SPIFFE-based
mutual authentication with an embedded SPIRE, gated per-flow by
`CiliumNetworkPolicy.authentication.mode: required`. The CNI, the policy CRD and the operator
are already deployed and already used by this estate.

**Option B — install Istio.** Per-connection mTLS with the workload identity carried in the
connection itself, plus the wider Istio surface.

### Risks

- ⚠️ **These are not equivalent, and the difference decides it.** Cilium's mutual auth performs
a SPIFFE handshake **out of band** and then permits the flow by policy; it authenticates
endpoint identity but does **not** itself encrypt — encryption is a separate Cilium feature
(WireGuard or IPsec), and neither is enabled here. Istio gives in-band mTLS where identity
and encryption are properties of the connection. If the requirement is "a request carries
cryptographic proof of its caller", Cilium's model does not provide it and Option A is the
wrong answer regardless of cost.
- ⚠️ **Istio would be a fourth data plane** beside Envoy Gateway, Envoy AI Gateway and Cilium.
Sidecar injection interacts with all three, and this cluster already had an outage from a
gateway-adjacent misconfiguration (the OPA-removal incident recorded in
`docs/migrations/2026-hetzner-cutover.md`). The operational cost is the main argument
against, and it is a real one.
- Cilium mutual authentication has been beta for several releases. Check its status in 1.19.4
before committing production traffic to it.
- Doing neither is a defensible outcome if topological trust plus SA tokens covers the actual
threat model. Say so explicitly rather than leaving the ticket open.

### Test Plan

Time-boxed spike; the output is an ADR, not code. If Option A, prove it on one non-critical
service pair — mutual auth enforced, and a policy-violating flow **refused** — before any
wider rollout. An enforcement mechanism that has never been observed refusing anything has
not been tested.