A route that fails to rebuild no longer keeps its old client-certificate policy

[Devin-Holland]

⊙ Problem

When a hot reload couldn't build a route, symphony kept serving the whole previous route, including its client verifier. A route updated to require client certificates kept admitting clients without one until a later reload succeeded. Reproduced on main through symphony-server (#62).

🤔 Is a policy-aware carry-forward the right size for this?

It closes the hole for every consumer (napi and symphony-server) and keeps mid-rotation cert/key failures serving. host-manager#254 doesn't depend on it. The "trust nothing" route from #62 item 3 is proposed on the issue, not built here.

💡 Solution

• A failed rebuild keeps the last-good route only while the new config asks for the same client-cert policy: passthrough, no client cert, or the same CA bundle and requireClientCert.
• Otherwise the SNI serves nothing. It doesn't fall through to a wildcard route.
• symphony-server keeps the requested mtls when a cert file can't be read. A terminating route whose CA file can't be read is dropped.
• When an SNI is configured twice, the winning entry (the last exact one, the first wildcard) controls routing even if rejected. A duplicate can't serve it under another policy.

⚖️ Alternatives

• Drop on every failed rebuild — breaks cert/key rotation, which writes two files non-atomically; that window is why carry-forward exists.
• Keep the policy on Route — every connection clones Route into its task; measured +32 B per connection (3384 → 3416 B).
• Fix only in server.ts — embedded napi consumers keep the hole, and TS can't predict which rustls builds fail.
• Reuse the old cert under the new verifier — serves a patched route instead of refusing, and needs new session-cache identity.

🤔 Should an unreadable CA file drop the route?

It does: the requested policy is unknown, and keeping the route could keep trusting a removed CA. A CA file caught mid-write leaves the route offline until the next reconcile. Rename-based rotation (what host-manager does) never hits this window.

🔧 Changes

• src/router.rs: ClientAuth is the policy a spec asks for, from effective_mtls, which build_route now shares. RouteTable.client_auth records it per installed route. The failure arm of build_route_table compares it before carrying forward, and drops the SNI through a shared tombstone helper. last_exact skips earlier exact duplicates, and the first wildcard now reserves its suffix before it is validated.
• src/tls.rs: sha256 is pub(crate) so the policy hashes the CA bundle the way the TLS cache keys it.
• ts/server.ts: resolveRoute reads the CA first; UNRESOLVABLE_MTLS represents an unreadable CA.
• CLAUDE.md, README.md: the carry-forward and duplicate rules. The README no longer says a rejected protocol declaration keeps serving last-good; it never did.

🤔 What about a listener-level CA?

Out of scope here. An unreadable or unbuildable listener mtls CA still leaves the old proxy, and its old policy, running. Failing closed there takes every route on the port down.

✅ Verification

• New tests fail on main at their behavior checks and pass here.
• src/router.rs: five unit tests. A changed policy drops the route, with no wildcard fallthrough, and stays dropped on repeat. Every policy change drops a failing route. An unchanged policy keeps last-good. A listener-inherited CA compares by effect. A rejected duplicate, exact or wildcard, isn't replaced by its sibling.
• __test__/server.spec.ts, through a spawned symphony-server (a probe counts only an echoed payload): a certless client is refused after mTLS is required with an empty CA. A deleted CA file refuses its clients, and restoring it heals the route. A deleted key file keeps an mTLS route serving. That last test fails with only the Rust half applied.
• Live probe against the built server, before → after: required-mTLS-with-empty-CA and CA-file-deleted went from connected to refused. Key-file-deleted routes, with and without mTLS, kept serving.
• cargo test 163 pass, clippy and cargo fmt --check clean, npm test 159 pass / 2 platform skips. Per-connection future unchanged at 3384 B. test:integration fails in setup locally on main too (needs a harper-pro build); CI runs it.

Live probe output (before → after)

A2 reloaded to required mtls with empty CA, certless client     CONNECTED → REFUSED (ECONNRESET)
B2 key file missing, policy unchanged, client with cert          CONNECTED → CONNECTED
B2 key file missing, policy unchanged, certless client           REFUSED   → REFUSED (certificate required)
C2 CA file missing, client with cert                             CONNECTED → REFUSED (ECONNRESET)
D2 key file missing, no mtls, certless client                    CONNECTED → CONNECTED

Fixes #62

_{🤖 Generated by Claude Opus 5.5 via Claude Code (devain); posted via @Devin-Holland.}

🤖 Generated with Claude Code

Release target: main — symphony ships from main; it has no release branches

Related PRs: none found
Complexity: complicated

_{Review-Coverage: authored=claude; ran=cursor-composer,gemini,codex,cursor-muse; blocked=domain(auth); declined=cursor-grok,cursor-kimi,muse; rounds=2; full=1 @ 5c33811}

_{Review-Attention: read ~6m (raised: degraded review) @ 5c33811}

[gemini-code-assist]

Code Review

This pull request ensures that when a route fails to rebuild during a hot-swap, its last-good version is only carried forward if the requested client-certificate policy remains unchanged. If the policy has changed, the route is dropped (tombstoned) to prevent an old verifier from outliving its replacement. This is implemented by introducing a ClientAuth enum and tracking client-certificate policies in the RouteTable. Additionally, the TypeScript server wrapper is updated to handle client CA resolution failures by returning an unresolvable mTLS configuration, and comprehensive integration and unit tests are added to verify these behaviors. I have no further feedback to provide as there are no review comments.