ALPN-based h2 upstream dispatch + fix silently-dropped JS-wrapper config fields

[kriszyp]

Summary

Completes the HTTP/2 story on the symphony side (pairs with HarperFast/harper#1707, Harper's cleartext-h2 UDS mirror): symphony stays a byte-pump — no HTTP parsing — and gains protocol-aware upstream dispatch.

• UDS upstreams can be marked protocol: 'h2' (matching the protocol: h2 line in Harper's -h2.sock UDS metadata yaml). build_destinations partitions a route's upstreams into the default (h1) destination + an optional destination_h2; after the TLS handshake, connections that negotiated h2 in ALPN are pumped to the h2 destination, everything else to the default.
• Config invariants (root-cause enforcement rather than runtime corruption): any h2-capable route (http2: true or h2-marked upstreams) rejects sourceAddressHeader: 'xForwardedFor' — header injection would splice into the middle of the h2 connection preface; PROXY protocol rides before the preface and works for both protocols. h2 upstreams on a passthrough route are also rejected (no ALPN visibility without terminating). All-h2-upstream routes are rejected (h1 clients need somewhere to go). Runtime backstop: suspended-route resolutions supply their own source mode, so h2-negotiated connections skip XFF injection instead of corrupting the preface.
• Bug fix riding along: toJsRoute/toJsUpstream in the TS wrapper were silently dropping fields the Rust side supports — route http2 (ALPN advertisement, dead since e72b220) and upstream pid/tid (the CPU-aware balancer tiebreaker) never reached the addon. Verified no deployed consumer sets http2: true (host-manager/central-manager grepped), so re-arming it has no blast radius, but reviewers should know the flag was inert until now.

Where to look

• src/router.rs build_destinations — the upstream partition + invariants.
• src/proxy_conn.rs — the post-handshake ALPN selection + runtime XFF guard.
• The dropped-fields fix in ts/proxy.ts is two mapping lines but is the reason the http2 option now does something.

Notes

• 6 new tests in __test__/h2-dispatch.spec.ts (dispatch h2/h1 with PROXY-precedes-preface byte-order assertions, plus the four config-rejection cases). Full suite 38/39 — the one failure (server.spec.js "writes a status file with pid and version", 0.5.0 vs 0.4.0) is pre-existing on main from the version-sync commit.
• cargo clippy pre-existing errors on main (cargo clippy --all-targets fails on main (10 pre-existing errors under deny(clippy::all), clippy 1.94) #21) unchanged by this diff.
• Cross-model review (Gemini diff-only + Harper-domain adjudication) ran pre-PR; its two significant findings (the XFF gap for non-split h2 routes, a racy test assertion) are fixed in the second commit. Open suggestion I deliberately did not take: promoting the http2/h2-upstream mismatch warnings to hard errors — warnings preserve the pre-existing behavior of http2: true alone.

Drafted by an LLM (Claude Fable 5).

[gemini-code-assist]

Code Review

This pull request introduces ALPN-based upstream dispatch, allowing HTTP/2 connections to be routed to specific h2-marked UDS upstreams while other traffic goes to default HTTP/1.x upstreams. It includes configuration validation to prevent invalid setups (such as combining HTTP/2 with X-Forwarded-For headers or using h2 upstreams without TLS termination) and adds comprehensive integration tests. The review feedback highlights three key improvements: forwarding the protocol field in the TypeScript wrapper to ensure TCP protocol validation is reachable, using safe slice access (.first()) instead of direct indexing to avoid potential panics, and replacing eprintln! with tracing::warn! to align with the application's logging framework.

[Ethan-Arrowood]

Approving — clean ALPN-based h2 dispatch, and the .first() panic-guard and protocol forwarding from the bot round all look good.

One thing I'd like you to confirm rather than block on: the dropped-fields fix also re-arms pid/tid, which were being dropped before this PR — so any UDS consumer whose Harper metadata sets them will now activate the CPU-aware balancer tiebreaker. The PR verifies http2 blast radius but not pid/tid, and that's the field most likely to be set in real deployments. Can you confirm the re-arm is intended/harmless, and ideally add a wrapper-level test asserting pid/tid/protocol survive toJsUpstream? Approving on the assumption this is the intended restore-designed-behavior fix.

Minor: worth a CHANGELOG entry for the new protocol config option (public docs can wait until symphony ships).

_{sent with Claude Opus 4.8}