deploy/compose: fresh deployment has no community, and the referenced bootstrap script does not exist

**Describe the bug**

A fresh `deploy/compose/` deployment has an empty `communities` table, so every request fails with `relay: no community is configured for this host` until a row exists. There is no documented bootstrap step, and `deploy/compose/README.md` refers to a bootstrap script that does not exist ("The bootstrap script should eventually replace manual `.env` editing").

The relay does provision a community from `RELAY_URL` on some paths, which is what eventually got us running, but nothing in the self-host documentation says so. Coming from the docs alone, a first-time self-hoster sees only the error.

Related but not the same: #5378 is the opposite problem (the relay seeding empty communities too eagerly). #3088 covers self-hosting onboarding friction generally.

**Steps to reproduce**

1. `cd deploy/compose && cp .env.example .env`
2. Fill in every `CHANGE_ME`, set `RELAY_URL` and `BUZZ_DOMAIN` to your hostname
3. `./run.sh start`
4. `curl https:///`

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

**Expected behavior**

A fresh single-community deployment should be reachable after `./run.sh start`, or the README should state explicitly which value provisions the community and when. `docs/multi-tenant-relay.md` describes the model ("one host, the one community"), but nothing connects that to the Compose bundle.

**Version and platform**

- Buzz version: relay `ghcr.io/block/buzz:latest` (NIP-11 reports 0.2.1), desktop 0.5.20
- OS: macOS 26.3, arm64, OrbStack

**Logs / additional context**

The host must match the normalised request host verbatim, port included, which is easy to get wrong when the relay sits behind a reverse proxy or tunnel on a non-default port. Worth calling out in the self-host docs alongside the provisioning step.