fix: sync canonical community names across clients - #7679

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.