fix: sync canonical community names across clients

[sbddesign]

A community named on one installation currently appears under a hostname-derived label on another. This adds one owner/admin-controlled name per relay community, read by Desktop and Mobile from host-scoped NIP-11 metadata.

Fixes #2797.

• Extend the existing signed kind:9033 profile command with a validated name patch. Names always require an explicit owner/admin, including on open relays. A name-only update preserves the icon; legacy icon commands preserve the name.
• Add nullable communities.name in migration 0046 and the desired-state schema. Expose it as standard NIP-11 name, with community_profile distinguishing supported/unset metadata from older relays. Clients check this capability before publishing: old relays would interpret a name-only command as an icon clear.
• Desktop adds Community settings → Community name → Save name. Desktop and Mobile cache names and refresh on launch/foreground/reconnect; Desktop also refreshes on window focus/network recovery and Mobile when opening its switcher. Presentation updates do not restart the relay connection.
• Preserve existing custom labels as explicit local nicknames. New connections, including invite-provided labels, follow relay truth. Generated hostname/IP labels follow the canonical name; previous labels remain available as fallback. Nicknames never update relay state. New IP-address fallbacks show the whole address.

The name is intentionally public through NIP-11, as the icon already is. The editor discloses that before saving. Mobile consumes canonical names; the shared-name administration path is Desktop.

Upgrade the relay before using the new editor. Existing rows remain unnamed until an owner/admin explicitly saves a name. Binary rollback leaves the additive column in place; old icon SQL continues to preserve names. The protocol, compatibility behavior, and rollout are documented in docs/nips/NIP-WP.md.

Validation on the implementation:

• Migration and real signed-command tests pass against isolated PostgreSQL: authorization (including rosterless rejection), host isolation, validation, idempotent retry, atomic icon preservation, legacy-client compatibility, and migration/re-upgrade preservation.
• The complete PostgreSQL database/relay lane passed 342/343 tests on local PostgreSQL 14. The existing huddle-links test fails on SQL syntax near JSON; the repository Docker environment specifies PostgreSQL 17.
• The complete relay/database unit run passed 1,162/1,163 tests. The unchanged mesh-demo forwarding test returned HTTP 504 instead of 200; it also reproduces with one worker and is not claimed resolved.
• Repository formatting/static checks, Rust/Tauri Clippy in both native configurations, TypeScript, and Flutter analysis passed. just ci was stopped during later Rust test builds when disk space fell to approximately 400 MB, so the full gate is not green. just test passed its unit phase, then could not start Docker services because the daemon is unavailable (stopped its service-wait loop); the isolated PostgreSQL lane above was used for database integration evidence.
• Full client suites: 6,506 Desktop tests; 2,235 Mobile tests plus three unconfigured-build tests. Desktop and web production builds pass. Two Chromium regressions cover shared rename/focus refresh across isolated storage profiles, nickname independence, community switching, offline restart, and rejecting name writes to old relays.

The browser tests use the established mocked native bridge and shared profile transport across two isolated storage profiles. They prove the client workflow; the PostgreSQL tests independently exercise the real signed command handler and NIP-11 producer. A rebuilt native Desktop/Mobile pair against an upgraded live relay has not been exercised, and the draft still needs the complete CI/PG17 gate before merge.

[github-actions]

🔐 Codex Security Review

Status: review required for the current range.

The current range is c507a4d488ca27796e78d876b9c24ee38442cc1b...7b41ab330cc10dedb254891ea31104782b2cd909.
A new review must complete for this exact range. When manual authorization
is required, a Block organization member must comment exactly
@buzz-security-review 7b41ab330cc10dedb254891ea31104782b2cd909 to authorize a new review.
Any previous review applies only to its recorded range.

[sbddesign]

Browser regression evidence at 7b41ab330: two isolated Chromium storage profiles using the test native bridge and shared profile transport. Both tests pass. Backend authorization, persistence, and tenant isolation are tested separately against PostgreSQL.

Installation A after saving the shared name; the optional local nickname remains a separate setting:

Installation B after a focus refresh, without manually renaming it: