[savme]

Envoy Gateway gives each HTTPS listener its own route configuration. A request that arrives on a connection opened for another of our hostnames therefore matches nothing and gets a 404. Browsers send such requests because managed hostnames share edge addresses and a certificate, so they may reuse one site's connection for another. Envoy Gateway guards against this only by not offering HTTP/2 where certificates overlap, which doesn't cover HTTP/3.

The extension server now adds a catch-all virtual host to every route configuration reached only through TLS or QUIC, answering 421 Misdirected Request, so the client retries on a dedicated connection. Only requests that match no site change; Envoy prefers any exact or suffix domain over *.

Setting ALPN h2 explicitly (required for modern gRPC clients) bypasses that guard, so this needs to be in place first.

Reproduce

curl --http3-only https://site-b.datumproxy.net/                                  # 200
curl --http3-only -H 'Host: site-b.datumproxy.net' https://site-a.datumproxy.net/ # 404 (today) -> 421 (after)

Test plan

• Unit tests for which route configurations are guarded and which are left alone
• E2E misdirected-request: 404 on main, 421 with the fix
• After deploy on staging: open a managed hostname you've visited before in a browser, then a second one, and reload the second

Fixes #661