fix(relay): let DM participants rename their own DM (#4739)

[bonpiedlaroute]

Fixes #4739.

Summary

Renaming a group DM is impossible for everyone, community owner included. The
kind:9002 privileged-tag gate (side_effects.rs:595) requires owner or admin,
but buzz-db/src/dm.rs enrols every DM participant with a hardcoded role —
VALUES ($1, $2, $3, 'member', $4), commented as an invariant ("always member
for DMs") — and a DM never carries an owner-role agent for the NIP-OA fallback
either. So this isn't a policy against renaming; it's an authorization predicate
no principal can satisfy.

Change

The handler already has the tier this needs, documented two lines above the check:
"topic/purpose allow any member", implemented with state.is_member_cached. name
now rides that tier for channel_type == "dm" only, behind is_dm_rename_only.
Every other privileged tag stays locked — a rename carrying
about/archived/visibility/ttl falls back to the owner/admin gate.

No new query: validate_admin_event already loads the channel record for the
archived-channel check, so channel.channel_type was in scope.

Why the rename actually lands

The gate is only half the path, so I traced the rest rather than assuming it:

• membership — is_member filters on removed_at IS NULL only, no role
  predicate (buzz-db/src/channel.rs:654), so a plain member passes;
• apply — handle_edit_metadata's name arm calls
  update_channel(name: Some(..)) with no channel-type condition
  (side_effects.rs:1445);
• propagate — emit_group_discovery_events pushes ["name", &channel.name]
  unconditionally (side_effects.rs:1057); the DM branch only adds hidden and
  p tags (:1073). It runs at the end of handle_edit_metadata (:1649).

Tests

Four unit tests on the predicate, no infrastructure needed. The one that matters
for review is dm_edit_touching_another_privileged_tag_stays_role_gated: it
asserts a rename cannot smuggle visibility or archived past the gate, for each
of the four locked tags.

cargo fmt --check, cargo clippy -p buzz-relay --all-targets -- -D warnings,
just test-unit and just desktop-tauri-test are clean.

Not included

Desktop excludes DMs from channel management entirely
(ChannelManagementSheet.tsx:142), so the UI unlock is a separate PR — happy to
follow up once the relay side lands.

The rule is isolated in one small pure predicate, so if you'd rather scope it
differently — creator-only, or a community-owner bypass — that's a one-function
change rather than a rework.