Feature Request: Supported path to migrate an existing managed community to a self-hosted relay

**Motivation**
What problem does this solve? Who runs into it and when?

Community owners who start on a Block-managed relay (`*.communities.buzz.xyz`) sometimes later want to self-host for data ownership — running their own infrastructure (e.g. a Railway or Docker deploy) without losing existing channels, history, and membership. Today there is no supported way to do this: pointing a self-hosted relay's `RELAY_URL` at its real domain does not "adopt" an existing community, it silently mints a brand-new one, because community identity is keyed by the relay's own advertised hostname. The owner is left with an empty, freshly-bootstrapped community and no path to bring over prior chat history, channels, or membership other than hand-rolling a Nostr event replay (and it is unclear whether server-derived state like search index, canvas, or workflow runs would even survive a replay).

That history is not just logs — it is shared memories, decisions, and months of accumulated agent context and history built up with the community's agents. Losing all of it is a genuinely bad outcome, and today it is the default result of doing the one thing self-hosting is supposed to enable: taking ownership of your own data.

**Proposed solution**
Describe what you'd like to see.

At minimum, one of:
1. A CLI/admin path to export a community's event history from one relay and import/replay it into another, preserving channels, membership, and (as much as is feasible) search index / canvas / workflow state — essentially "move my community."
2. A way to set a self-hosted relay's community identity explicitly (env var or bootstrap flag carrying the target community ID) instead of always re-deriving it from the relay's own hostname, so an owner can point a fresh self-hosted deploy at their existing community ID rather than always minting a new one.
3. Short of either: clear documentation that changing/setting a relay's `RELAY_URL` re-keys the community by hostname (a landmine — see also #5109, #3601, #6233 for related fallout from the same design), so owners do not discover it only after redeploying.

**Alternatives considered**
What other approaches did you consider?

- Hand-writing a Nostr event replay script (fetch all events for the old community, republish to the new relay). Possible in principle but fragile — no guarantee server-derived state round-trips, and every client (agents' `BUZZ_RELAY_URL`, Buzz Desktop, mobile, workflows) still needs to be repointed by hand afterward.
- Staying on the managed relay. Works, but defeats the actual motivation (data ownership / running your own infrastructure).

**Additional context**
Anything else that helps — links, screenshots, prior art.

Related issues found searching before filing (none is an exact duplicate of "support migrating a community," but all touch the same "relay identity keyed by hostname" area):
- #6764 — `BUZZ_RELAY_URL` silently ignored, relay binds to `localhost:3000` and 404s everything; same underlying hostname/identity-binding mechanism this request is about.
- #5109 — editing a community's Relay URL orphans the existing Welcome Team and mints a fresh Fizz/Honey/Bumble trio.
- #3601 / #6233 — changing a relay's canonical URL leaves avatars / historical attachments pinned to the old media origin.
- #2816 — self-host onboarding dead-ends when you already own the community (only offers Builderlab, never a relay URL) — likely the first wall most people hit before even getting this far.
- #6521 — another user actively self-hosting right now, stuck on a different part of the same journey (mobile pairing).
- #3554 — RFC for headless/self-host machine enrollment; adjacent self-host UX gap, not this one specifically.