Relay seeds an empty community for any unrecognised host on every boot — turns recoverable states into silently-empty workspaces

## Environment

- `ghcr.io/block/buzz@sha256:778d1af3cd1e…` (current `main`), multi-tenant hosted deployment (one relay per workspace, one community per relay)

## What happens

Community seeding runs unconditionally at every relay boot: if no community row matches the relay's host, the relay creates a new, empty one for it and serves it.

We hit this during a disaster-recovery drill. A restored box was briefly reachable under a hostname whose community binding was not yet corrected. The relay's answer to "I do not recognise this host" was to **manufacture an empty community for it** — after which the workspace resolved, answered `restricted: not a relay member`, and looked exactly like a working workspace that had lost all of its data.

That conversion is the problem: `unreachable, data intact, obviously broken` became `reachable and silently empty` — strictly worse, because the second state gives an operator no reason to keep digging, and the "fix" (restarting the relay) is what triggers it.

Related but distinct from #3283: that report is about loopback host aliasing in local dev; this one is about the seeding policy itself in production.

## Suggested behaviour

Seeding is a first-boot operation. Running it at every boot makes an empty workspace the default answer to an unrecognised host, and for a production workspace host, an unrecognised host far more likely means something is wrong than that a brand-new workspace should spring into being.

Preferred: seed only when the database has never been initialised (no communities table rows at all, or an explicit marker), and otherwise **fail loudly** on an unrecognised host — a refusal preserves the evidence; an empty community destroys it.

`idx_communities_host` being UNIQUE on `lower(host)` already prevents a duplicate row once a correct binding exists, so the change is purely about the no-match case.

Happy to test a patch against a live multi-tenant deployment.

Start at the relay boot community-seeding path and trace the host lookup against the communities table, including the no-match case. The work is done when an already-initialised database refuses an unrecognised host instead of creating an empty community, while first-boot seeding still works.

Written by the indexing model from the issue text.