(feat) Community-configurable Max Identities for Group DMs

**Motivation**
What problem does this solve? Who runs into it and when?

Group DMs are useful for small, private coordination, but once they get large they start competing with channels. Group DMs have worse discovery, weaker moderation affordances, and chat that belongs in a room. Today the relay hard-caps DM participant sets at **9 identities**. That legacy number is reasonable as a default, but community owners cannot lower it (to nudge people into channels) or raise it slightly for a known small team without changing code / redeploying.

Operators who run Buzz as a community workspace may want **per-community** control over how large a DM can grow, consistent with “your community, your rules” (owners/admins set policy; the relay enforces it).

**Proposed solution**
Describe what you'd like to see.

Make the group-DM identity cap a **per-community policy**, stored on the `communities` row and enforced by the relay (not a client-only soft limit, and not a single global env flag for the whole process).

Sketch (happy to adjust):

1. **Schema** (additive migration on `communities`):
- `dm_group_max_identities INTEGER NULL` — max identities in a DM; `NULL` = keep today’s legacy cap of **9**
- Constraint: `NULL` or `>= 2`

2. **Admin command** — new kind in the relay-admin range, e.g. **9034** `RELAY_ADMIN_SET_DM_POLICY`, gated like **9033** (owner/admin; same steward semantics as workspace profile). Partial update via tags; omit = leave unchanged; empty string clears back to `NULL` / legacy default.

3. **Enforcement**
- On **create DM** / **add member** paths (`create_dm`, add-member command handling)
- Effective cap = configured value, else 9
- **Re-open** of an existing DM that already exceeds a newly lowered cap remains allowed (don’t trap people out of history); new creates / adds must respect the current cap

4. **Read path** — advertise effective policy on NIP-11 (e.g. `dm_policy.dm_group_max_identities`) so desktop/mobile can fail early in the new-message picker. Relay remains source of truth.

5. **Desktop** — Settings → community **DM policy** field for owners/admins (alongside any related DM toggles if those land separately).

6. **Defaults** — unchanged behavior when unset (`NULL` → 9). Additive; no migration of existing DMs required.

**Alternatives considered**
What other approaches did you consider?

| Alternative | Why we’re not leading with it |
|-------------|-------------------------------|
| Global env / config on the relay binary | Breaks multi-community hosts; doesn’t match 9033-style community settings |
| Client-only picker limit | Bypassable; CONTRIBUTING / architecture treat the relay as source of truth |
| Hard-delete / lock existing oversized DMs when cap drops | Punitive; re-open + block growth is enough for v1 |
| NIP-29 groups instead of DMs | Different product surface; this is specifically about Buzz DM channels |

**Additional context**
Anything else that helps — links, screenshots, prior art.

- Duplicate search: none found for “group DM max participants / identity cap” (please close as dup if I missed one).
- Looking for maintainer feedback on the approach (especially kind number, 9033-shaped gate, and “re-open oversized still allowed”) before opening a PR, per CONTRIBUTING.