`BUZZ_RELAY_URL` is silently ignored; relay binds the community to `localhost:3000` and 404s every request

Self-hosting a relay, I set `BUZZ_RELAY_URL` (matching the `BUZZ_*` prefix of every other variable in `deploy/compose/compose.yml`) and the relay started cleanly — logs showed `Postgres connected`, `Database migrations complete`, `Deployment community ensured`, healthcheck green.

But every request to `/` returned 404, including the WebSocket upgrade. Clients could not connect at all.

The variable the relay actually reads is `RELAY_URL`. `BUZZ_RELAY_URL` is accepted into the process environment and silently ignored, so `relay_url` stays at its default `ws://localhost:3000`. The deployment community is then created bound to host `localhost:3000`, and since the relay resolves the tenant from the `Host` header, no real request ever matches.

The only signal is the 404 body:

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

That message is deliberately generic so an unauthenticated caller cannot probe which hosts are mapped, which is the right call for the security property — but it also means an operator who mistyped one variable has nothing to go on. The startup log line `Config loaded ... relay_url=ws://localhost:3000` is the only place the truth appears, and it is easy to miss among the healthy-looking lines around it.

I lost several hours to this and only found it by reading `router.rs`.

**Suggestions, roughly in order of value**

1. Warn at startup when `BUZZ_RELAY_URL` is present in the environment but `RELAY_URL` is not. It is a near-certain operator mistake given every neighbouring variable is `BUZZ_`-prefixed.
2. Accept `BUZZ_RELAY_URL` as an alias.
3. Make the startup log line for `relay_url` prominent (or warn when it is still the default while `BUZZ_BIND_ADDR` is a non-loopback address).

Happy to send a PR for (1) if that is the direction you would take.

**Environment**: relay `ghcr.io/block/buzz:main`, self-hosted via `deploy/compose`, single tenant behind a TLS reverse proxy.