external API request handling could verify Host/authority matches TLS certificate's server name

Today, I believe that external API request handling works like this:

• Nexus operates a bunch of different per-silo HTTPS endpoints, but all on the same set of external IPs.
• Nexus determines which TLS certificates to used based on the TLS SNI that the client sends. The upshot is that when you go to silo A's endpoint, you get one of silo A's certificates.
• After establishing the TLS session, Nexus uses the "host" header (HTTP 1.0) or authority (HTTP 2) to determine which silo you're operating on. This determines which credentials are acceptable, which identities these resolve to, what API resources are visible, etc.
• Nexus does not validate that the silo determined for the HTTP request matches the silo determined for the TLS session.

It's this last bit that's potentially questionable. This means that today you can probably establish a TCP connection to Nexus, send a TLS SNI specifying silo A's endpoint, use silo A's TLS certificate, and then send a request to silo B (that will be processed like any other normal request to silo B).

This isn't as bad as it might sound because you still have to authenticate with a credential that's valid for silo B, and you will still only be able to see the stuff that's in silo B. It is exactly the same as actually having connected to silo B's endpoint except that you're using silo A's TLS certificate to do it. The only security impact I can imagine this having is that if the customer is expecting certain security properties by virtue of the certs (e.g., stronger encryption), and they're different across silos (e.g., because one is more sensitive than another), they may be surprised to find those properties not holding for some silo.

This is related to #11240. Enforcing this may require sending a 421 ("Misdirected request") response (and verifying that browsers deal with that well).

No file or test is named; start by tracing external API request handling from TLS SNI through HTTP Host or HTTP/2 authority processing. Determine how a mismatch should be detected and whether a 421 response is appropriate, then verify that the request cannot be processed for a different silo and that browser behavior is covered.