[Bug] Community name remains device-local instead of syncing from relay

## Problem

Buzz Desktop treats a community's human-readable name as device-local
configuration rather than community state.

When the same owner identity connects to the same self-hosted community from a
second Desktop installation, the second device does not receive the name chosen
on the first device. It derives a new label from the relay hostname instead. For
an observed private IPv4 relay whose first octet was `100`, the derived name was
`100`.

Every installation must therefore rename the same community independently. The
result is especially confusing because the relay already provides other
per-community presentation state, including the workspace icon, and Buzz's
architecture describes the relay as the source of truth.

The local label is not authorization state, and this behavior does not change
owner/admin roles. The problem is that users cannot establish one canonical
community name that follows the community across supported clients.

## Evidence And Reproduction

### Environment

- Observed Desktop release: `v0.4.25`
- Release commit:
`e8105d1446834f522c75d628bf1d9e77c9c077a4`
- Observed OS: macOS on two separate installations
- Relay: self-hosted Buzz relay reached through a private IP WebSocket URL
- Identity: the same imported Nostr owner identity on both installations
- Current `main` rechecked at:
`9cc9652c7dec9145b0bf0ce2c4b46c8191d215f8`

### Minimal reproduction

1. Connect Desktop installation A to a self-hosted Buzz community.
2. Rename the locally displayed community to `TheHive`.
3. On Desktop installation B, import the same Nostr identity.
4. Connect installation B to the same relay URL.
5. Observe that channels, messages, profile, and membership load from the
relay.
6. Open the community editor on installation B.
7. Observe that the community name was not received from the relay. For a relay
addressed by a private IPv4 host beginning with `100`, Desktop derives
`100`.
8. Rename installation B to `TheHive`.
9. Observe that the rename affects only installation B and does not establish
canonical community state for future installations.

### Current result

- The same community can have unrelated names on different Desktop
installations.
- Each installation persists its own name in `buzz-communities` local storage.
- `deriveCommunityName()` splits the relay hostname and uses its first segment,
producing `100` for the example IP.
- The relay's community record has stable `id` and `host` fields plus
per-community `icon`, but no canonical name.
- NIP-11 exposes a `name` field, but Buzz currently serves the static value
`Buzz Relay` rather than the requesting community's name.
- Desktop fetches and caches the relay-provided community icon but has no
equivalent community-name read path.

### Evidence classification

**Observed**

- Two macOS Desktop installations using the same owner identity and relay
displayed different locally configured community names.
- The second installation loaded relay-backed channels and history but derived
`100` as its community name.
- Both installations required a manual rename.

**Code-proven**

- `desktop/src/features/communities/communityStorage.ts` persists community
records in local storage and derives an unnamed community from the first
hostname segment.
- `crates/buzz-db/src/lib.rs::CommunityRecord` models only the stable community
id and host; the current community presentation column is `icon`.
- `crates/buzz-relay/src/nip11.rs::RelayInfo::build` emits the static name
`Buzz Relay` while accepting a host-scoped community icon.
- `desktop/src-tauri/src/commands/workspace.rs::fetch_workspace_icon` reads only
the NIP-11 icon.
- The same behavior remains on current `main` at the SHA above.

**Documented**

- NIP-11 defines a human-readable relay `name`.
- PR #2549 explicitly describes Desktop community records as device-scoped and
persisted in local storage.
- Issue #2667 proposes syncing community ordering or falling back to local
storage, but does not define or synchronize a canonical community name.

**Not yet runtime-proven in this report**

- No raw relay database row or NIP-11 response from the observed private
deployment is attached. The absence of a canonical name field and the static
NIP-11 value are code-proven at the release and current-main commits.

### Duplicate search

Open and closed issues and pull requests were searched for:

- `canonical community name`
- `"community name" sync devices`
- `NIP-11 name desktop`
- `"device-scoped" community name`
- `community name sync`
- `rename community`

No dedicated issue for canonical community-name synchronization was found as of
2026-07-25.

## Expected Behavior

Buzz should have one owner/admin-controlled canonical name for each community.

- The canonical name is relay-backed community state.
- A fresh supported client displays that name after connecting.
- Renaming the community through a supported owner/admin path becomes visible
on other clients after refresh or reconnect.
- The name is scoped to the host-derived community and cannot leak across
communities in a multi-tenant deployment.
- Unauthorized members cannot change it.
- Community id, host, membership, channels, messages, icon, and other state are
preserved during rename.
- If local aliases remain supported, they are explicitly labeled as local and
never silently replace or mutate the canonical name.
- A relay with no canonical name has a documented compatibility fallback; an IP
address is not presented as an intentional community name without
explanation.

The exact wire representation is a design decision. The visible invariant is
that users name the community once, not once per device.

## Scope

- Relay-backed, per-community canonical presentation metadata for the name.
- Owner/admin authorization for setting or changing the canonical name.
- A tenant-safe client read/discovery path.
- Buzz Desktop onboarding, community storage, refresh, editing, and fallback
behavior.
- Migration and compatibility behavior for existing communities and existing
Desktop local names.
- Focused relay, Desktop, and two-installation validation.

Owner boundary: the `block/buzz` community-presentation contract across its
relay and Desktop implementations.

## Non-Goals

- Making a community name globally unique.
- Changing the community's stable id, hostname, relay URL, owner identity, or
membership roles.
- Synchronizing user-specific community ordering, colors, notification
preferences, repository directories, API credentials, or local archives.
- Public DNS, TLS, NIP-05, or hosted-community provisioning.
- Broad community-settings redesign.
- Reworking the already relay-backed workspace-icon contract.
- Implementing cross-relay account synchronization.
- Selecting a new event kind or database schema before the contract is
accepted.

## Acceptance Criteria

- [ ] An owner or admin can set a canonical community name through a supported
path.
- [ ] A regular member cannot change the canonical name.
- [ ] Two clean Desktop installations connected to the same community display
the same canonical name without manually duplicating it.
- [ ] A rename on installation A becomes visible on installation B after the
documented refresh/reconnect boundary.
- [ ] The relay read path returns only the name of the host-derived community.
- [ ] Two communities served by shared infrastructure can use different names
without leakage or cache-key collision.
- [ ] A failed or unauthorized rename preserves the previous canonical name
and all unrelated community state.
- [ ] Retrying an accepted rename is safe and idempotent.
- [ ] Existing communities without canonical names remain accessible and use a
documented fallback.
- [ ] Existing local Desktop names are migrated or reconciled without silently
overwriting an intentional local alias.
- [ ] Offline or temporarily unreachable clients may show cached presentation
state but clearly reconcile with relay truth when connectivity returns.
- [ ] Community icon, membership, channel, message, profile, and relay
connection behavior remain compatible.

## Validation Plan

- Add focused unit tests for canonical name validation, authorization,
persistence, and idempotent rename.
- Add multi-community tests proving host-scoped reads and writes cannot cross
tenant boundaries.
- Add migration tests for communities created before the canonical-name
contract.
- Add Desktop tests for first connect, cached display, refresh/reconnect,
rename, unauthorized failure, offline fallback, and any explicit local-alias
behavior.
- Add a supported-path integration test using two clean Desktop storage
profiles against one relay.
- Prove the exact relay response/state before and after rename and the
operator-visible value on both clients.
- Run the repository-required focused suites, relay integration tests, Desktop
E2E tests, and `just ci`.
- Record exact-head evidence and migration/recovery proof in the implementation
PR. Auto-review belongs to that PR and is not pre-claimed by this issue.

## Security And Compatibility

- The canonical name must use existing owner/admin authority and must not create
a second administration plane.
- No private keys, API tokens, repository paths, private channel content, or
unredacted deployment data are required.
- If the name is published through unauthenticated NIP-11, it becomes
intentionally public to anyone who can reach that community host. That
exposure must be documented and accepted as part of the contract.
- Multi-tenant host binding and cache scoping must prevent name enumeration or
leakage across communities.
- Existing community ids, hosts, memberships, events, icons, and Desktop
connections must remain valid.
- If persistence changes, the migration must have a safe fallback for existing
rows and a tested rollback/recovery story.
- No additional network exposure, relay publication target, or credential scope
is required.

## References

- NIP-11 — Relay Information Document:
https://github.com/nostr-protocol/nips/blob/master/11.md
- Current Desktop community local storage and name derivation:
https://github.com/block/buzz/blob/9cc9652c7dec9145b0bf0ce2c4b46c8191d215f8/desktop/src/features/communities/communityStorage.ts
- Current relay community record:
https://github.com/block/buzz/blob/9cc9652c7dec9145b0bf0ce2c4b46c8191d215f8/crates/buzz-db/src/lib.rs
- Current NIP-11 builder:
https://github.com/block/buzz/blob/9cc9652c7dec9145b0bf0ce2c4b46c8191d215f8/crates/buzz-relay/src/nip11.rs
- Current Desktop NIP-11 icon reader:
https://github.com/block/buzz/blob/9cc9652c7dec9145b0bf0ce2c4b46c8191d215f8/desktop/src-tauri/src/commands/workspace.rs
- PR #2549 — local community ordering and device-scoped storage:
https://github.com/block/buzz/pull/2549
- Issue #2667 — adjacent community ordering/color synchronization proposal:
https://github.com/block/buzz/issues/2667

Start by reading desktop/src/features/communities/communityStorage.ts, crates/buzz-db/src/lib.rs, crates/buzz-relay/src/nip11.rs, and desktop/src-tauri/src/commands/workspace.rs to trace current local naming and relay metadata paths. The exact wire contract and authorization model still need design agreement; done requires focused relay and Desktop tests covering tenant scoping, migration, permissions, refresh, fallback, and two clean installations, plus the required CI suites.

Written by the indexing model from the issue text.