Per-owner community limit is hardcoded (MAX_COMMUNITIES_PER_OWNER = 3), blocking multi-tenant operators

[leesalminen]

Problem

MAX_COMMUNITIES_PER_OWNER is a hardcoded const (crates/buzz-db/src/relay_members.rs), enforced in community provisioning (create_community_with_owner) and ownership transfer. On a self-hosted multi-tenant deployment (one relay serving many communities via host-based tenancy), the operator's identity hits the cap of 3 almost immediately.

The failure mode is also confusing: POST /operator/communities returns a 409 whose body is limit_reached: owner already owns the maximum number of communities, but since community already exists uses the same status code, provisioning frontends tend to collapse both into "that subdomain is already taken" — which sends the operator chasing a name conflict that doesn't exist (mine did exactly that).

Reproduction

1. Provision 3 communities owned by the same pubkey via POST /operator/communities.
2. Provision a 4th with a fresh, unused host.
3. GET /operator/communities/availability reports the host as available, but the create call 409s with limit_reached.

Proposal

Make the limit deployment-configurable via an env var (BUZZ_MAX_COMMUNITIES_PER_OWNER), defaulting to the current 3 so existing deployments are unaffected. Enforcement should stay in the authoritative relay-layer checks — this is purely about making the ceiling operator-tunable.

PR: #2599

🤖 Generated with Claude Code

[Christian-Sidak]

Opened a fix in #2675 -- makes the per-owner community limit configurable via BUZZ_MAX_COMMUNITIES_PER_OWNER env var (falls back to the existing default of 3, so current deployments are unaffected). Note: #2599 addresses the same issue and is currently fully passing CI.