feat: emit system messages for channel renames

[thesid42]

Summary

• emit a kind-40099 name_changed system event when a channel's canonical display name changes
• include the actor, previous name, and new name while retrieving the stored previous name atomically with the update
• render channel rename events in Desktop and mobile timelines, with fallback copy when the previous name is unavailable
• add focused relay, integration, Desktop, and mobile coverage

Related issue

Fixes #5618

Testing

• cargo fmt --all -- --check
• cargo clippy -p buzz-relay -p buzz-db --all-targets -- -D warnings
• cargo test -p buzz-relay channel_name_change --lib
• cargo test -p buzz-test-client --test e2e_relay test_channel_rename_emits_persistent_system_message -- --ignored --exact --nocapture
• cd desktop && node --experimental-strip-types --test src/features/messages/lib/systemEventCopy.test.mjs
• cd desktop && tsc --noEmit
• cd desktop && pnpm lint
• cd mobile && dart format --output=none --set-exit-if-changed lib/features/channels/timeline_message.dart test/features/channels/channel_detail_page_test.dart test/features/channels/timeline_message_test.dart
• cd mobile && flutter analyze lib/features/channels/timeline_message.dart test/features/channels/channel_detail_page_test.dart test/features/channels/timeline_message_test.dart
• cd mobile && flutter test test/features/channels/timeline_message_test.dart test/features/channels/channel_detail_page_test.dart
• manually created and renamed a channel through the native Desktop app, verified the live timeline row, reloaded the app, and confirmed the persistent kind-40099 event in Postgres

[Copilot]

Pull request overview

Adds a new relay-emitted kind-40099 system event (name_changed) for channel renames, propagating it through the DB update path and rendering it in both Desktop and mobile timelines with targeted coverage across layers.

Changes:

• Relay: emit name_changed system messages on successful kind-9002 channel rename edits.
• DB: add an atomic update_channel_name helper returning (previous_name, name) to support accurate system/audit messaging.
• Clients/tests: parse + render rename system messages in Desktop and mobile, with unit/widget/E2E coverage.

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
mobile/test/features/channels/timeline_message_test.dart	Adds parsing + description tests for name_changed system events (including no-previous-name fallback).
mobile/test/features/channels/channel_detail_page_test.dart	Widget coverage ensuring name_changed renders correctly in the channel timeline UI.
mobile/lib/features/channels/timeline_message.dart	Adds nameChanged to SystemEvent parsing and human-readable copy for timeline rendering.
desktop/src/features/messages/ui/SystemMessageRow.tsx	Renders name_changed by mapping payload fields to a dedicated copy helper.
desktop/src/features/messages/lib/systemEventCopy.ts	Introduces describeChannelNameChange(previousName, name) copy helper.
desktop/src/features/messages/lib/systemEventCopy.test.mjs	Unit tests covering rename copy with and without previous_name.
crates/buzz-test-client/tests/e2e_relay.rs	E2E test validating live delivery + persistence of the relay-signed name_changed system message.
crates/buzz-relay/src/handlers/side_effects.rs	Emits the name_changed system message after a successful DB rename and adds focused unit tests for content helpers.
crates/buzz-db/src/lib.rs	Exposes Db::update_channel_name API for relay use.
crates/buzz-db/src/channel.rs	Implements transactional update_channel_name with SELECT ... FOR UPDATE to return stable previous/new names.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Chessing234]

the no-op rename path is the one thing that isn't really covered. it's reachable — canonical_channel_name means a client resending " ###foo " against a stored "foo" lands there — but should_emit_channel_name_change is just != and its test asserts !("same-name" != "same-name"), so nothing exercises the guard through handle_edit_metadata. the e2e only covers the renamed path; an assertion that a same-name kind:9002 emits zero 40099s is the one that could actually fail.

rest looks right to me — checked that this is the only rename call site so the FOR UPDATE pair really is atomic, that create_channel canonicalizes too so there's no spurious first-rename event, and that both clients drop unknown system types so older builds are unaffected.

[thesid42]

@Chessing234 Added end-to-end coverage for an accepted canonical no-op rename. The test submits a display-equivalent name with leading hashes and whitespace, then verifies that no live kind-40099 event is emitted and no additional name_changed event is persisted. Addressed in b0ba8bb.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (2)

crates/buzz-test-client/tests/e2e_relay.rs:357

• Same flakiness risk as the earlier block: recv_event can legitimately yield non-Event messages shortly after the rejected rename. The test should only fail if an unexpected kind:40099 Event arrives, and otherwise tolerate NOTICE/EOSE like other tests in this file.

    match client.recv_event(Duration::from_millis(500)).await {
        Err(TestClientError::Timeout) => {}
        Ok(RelayMessage::Event { event, .. }) if event.kind == Kind::Custom(40099) => {
            panic!("failed rename emitted system message {}", event.id)
        }
        Ok(other) => panic!("unexpected relay message after failed rename: {other:?}"),
        Err(error) => panic!("unexpected receive error after failed rename: {error}"),

crates/buzz-test-client/tests/e2e_relay.rs:313

• This assertion can be flaky because recv_event may return non-Event relay messages (e.g. NOTICE/EOSE) within the 500ms window. Elsewhere in this file those messages are treated as acceptable when asserting that no Event arrived; doing the same here avoids false failures while still catching an unexpected kind:40099 emission.

This issue also appears on line 351 of the same file.

    match client.recv_event(Duration::from_millis(500)).await {
        Err(TestClientError::Timeout) => {}
        Ok(RelayMessage::Event { event, .. }) if event.kind == Kind::Custom(40099) => {
            panic!("canonical no-op rename emitted system message {}", event.id)
        }
        Ok(other) => panic!("unexpected relay message after canonical no-op rename: {other:?}"),
        Err(error) => panic!("unexpected receive error after canonical no-op rename: {error}"),

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.