authn should validate that the user belongs to this endpoint's Silo

Nexus runs an external endpoint for each Silo. In a real system, Nexus determines which endpoint is being used based on the HTTP/1.1 "Host" header or HTTP/2 authority pseudo-header. If you come to https://eng.sys.$domain we know you're reaching the "eng" Silo's endpoint. This works for both authenticated and unauthenticated requests. During successful authentication, we will look up a user's session cookie or device authn token and then wind up with an identity that's associated with a particular Silo. There's nothing to verify that these two Silos match. You could totally take your session cookie for an identity in the "eng" Silo and use it at https://finance.sys.$domain. This shouldn't allow you to do anything or see anything that you couldn't access at https://eng.sys.$domain -- it should behave exactly like https://eng.sys.$domain -- but it's confusing and seems like a way we might accidentally introduce vulnerabilities.

This is all pretty straightforward in the case of a real system where people have deployed TLS and delegated external DNS to the rack. We'll need to figure out what to do for development systems, where people usually don't use TLS and don't use DNS -- they access the endpoint by IP address. I'd suggest we have a dev-only configuration knob that just skips this check since it doesn't make sense in this configuration. And again, it shouldn't be load-bearing for security.

(pulled from #849)

The issue names no files, tests, or entry points, so begin by locating authentication handling and how the request endpoint's Silo is identified. Done means an authenticated identity cannot be used across Silo endpoints, while development systems without TLS or DNS have an explicit way to skip the check.