Closed-relay production defaults lock the desktop out of its own relay — no invite/token-mint path exists

## Summary

With the production `deploy/compose/.env.example` defaults (`BUZZ_REQUIRE_AUTH_TOKEN=true`), the desktop's join flow demands an invitation token, but no command in the shipped tooling can mint one. A self-hoster following the official compose README cannot join their own relay from the desktop, even as an already-added member.

## Environment

- Desktop: Buzz.app 0.4.26 (macOS, Tauri/WKWebView)
- Relay: official `deploy/compose` bundle, image `ghcr.io/block/buzz:sha-0096d71@sha256:32a8c6aa8ca3617d767eb5743891f45d956c9cdbe161d244c8702a7645b64a78` (v0.4.26, commit `0096d710`)
- `.env` left at production defaults from `.env.example`: `BUZZ_REQUIRE_AUTH_TOKEN=true`, `BUZZ_REQUIRE_RELAY_MEMBERSHIP=true`, `BUZZ_ALLOW_NIP_OA_AUTH=true`

## Steps to reproduce

1. Deploy `deploy/compose` per the README, `.env` at closed-relay defaults above.
2. Add the desktop identity's pubkey as a member: `./run.sh add-member --role admin`. Confirmed via `buzz-admin list-members` — row present.
3. Desktop → Add/join community → enter the relay `wss://` URL.
4. Desktop shows **"MEMBERSHIP REQUIRED / This relay requires an invitation. Ask a relay admin to add you as a member, then come back and try again"** — displaying the npub of an identity that *is* a member (decoded and byte-compared against the admin row — identical).
5. Relay logs during the attempt: HTTP bridge requests authenticated as that pubkey (signature verified, pubkey logged) → `403` on `/query` and `/events`.

## What I found

`buzz-admin --help` at this commit offers only `add-member`, `remove-member`, `list-members`, `generate-key`, `migrate`, `product-feedback`, `reconcile-channels` — confirmed against the `Command` enum in `crates/buzz-admin/src/main.rs`. There is no `mint-token`/invite-creation command, and the desktop can't create an invite for a community it can't join. The `buzz` CLI authenticates fine with membership alone (NIP-42 path) — the token gate only bites the desktop's HTTP-bridge path. So with `BUZZ_REQUIRE_AUTH_TOKEN=true` (the shipped production default), the first desktop user of a fresh self-hosted relay does not appear to have a satisfiable join path through the shipped admin/desktop tooling.

Related: `crates/buzz-cli/TESTING.md` and `crates/buzz-acp/README.md` both still document a `buzz-admin -- mint-token` invocation for minting test credentials — that command doesn't exist anywhere in the current source (`git grep` for `MintToken`/`mint_token` across all `.rs` files returns nothing). Separate stale-docs issue, possibly the same removal that left this gap.

## Workaround

Set `BUZZ_REQUIRE_AUTH_TOKEN=false` (keep `BUZZ_REQUIRE_RELAY_MEMBERSHIP=true`), recreate the relay. Desktop joins immediately; non-member keypairs are still correctly rejected (`403 relay_membership_required`, separately verified with a throwaway key).

## Suggested fixes (any one resolves it)

- Ship a `buzz-admin mint-token`/invite command
- Have the desktop fall back to NIP-42 + membership when it holds no token
- Change the `deploy/compose/.env.example` default
- At minimum, document the flag flip in the compose README

## Related

- #2816 (fixed via #2824) routes self-hosters to the "enter relay URL" screen correctly — but that's a UI-routing fix. A member who reaches that screen via the now-fixed path will still hit this issue's lockout immediately after, since it's a separate backend auth-gate problem.