Community routing is bound to a single host — is serving one community over both an internal and a public address supported?

### Environment

- Self-hosted relay via `deploy/compose`, using `compose.caddy.yml` with Caddy terminating TLS
- Relay image `ghcr.io/block/buzz:sha-318fbf8`
- Docker Compose v5.1.0

### What I was doing

Migrating a relay that was originally deployed on a private network address (Tailscale-only) so it is *also* reachable over public TLS, while keeping the private path working for agents that already use it.

### What happens

Any request arriving with the public `Host` header is rejected before any auth logic runs:

```
HTTP 404
relay: no community is configured for this host
```

The same relay, same port, same process — only the `Host` header differs:

```
Host: 10.0.0.1:3001 -> 200 {"name":"Buzz Relay", ...}
Host: public.example.com -> 404 relay: no community is configured for this host
```

The `communities` table has a single row whose `host` column holds the address the relay was first started with.

### Question

Is one community reachable over two addresses (an internal one and a public one) a supported configuration?

Specifically:

- Is adding a second `communities` row for the public host the intended approach — or does that create a genuinely separate community with its own channels and membership?
- Is a single canonical hostname the intended design, so that migrating means updating the existing row and re-pointing all clients?

If the latter, it might be worth calling out in the deployment docs: a relay first brought up on an internal address effectively pins that address as its identity, and moving to a public hostname later is not just a DNS/proxy change.

Rewriting `Host` at the reverse proxy does resolve *this* particular 404, but it then runs into a second, separate problem with NIP-98 auth — filed separately.

The relay behaves correctly and fail-closed throughout. This is purely about multi-address support.