feat(buzz-relay): idempotent owner community deletion with quota reservation

[TheSentinel454]

Summary

This is the relay side of owner community deletion.

• Idempotent delete is the recovery call.
  • POST /operator/communities/delete checks the request UUID first.
  • If the request already exists with the same host, owner and acknowledgement version, it returns 202 with the request's current status. That holds at any stage, even after membership is purged, and no new work is admitted.
  • The same UUID with a different host or owner returns 409 deletion_request_conflict. An unsupported acknowledgement version is rejected first, with 400 unsupported_acknowledgement_version.
  • There's no receipt endpoint. Clients recover by resending.
• Active quota reservation. An incomplete owner deletion holds the owner's slot until the deletion logically completes. Migration 0054 adds the supporting index. Migrations 0052 and 0053 are unchanged.
• Lifetime cap. Deleted communities keep their hosts as permanent tombstones.
  • On create and on transfer-in, the relay counts live ownership plus every non-aborted owner deletion, completed ones included.
  • That total is capped at an absolute 20, regardless of the active limit, and going over returns limit_reached.
  • This stops create-then-delete host squatting.
• Stable lifecycle conflict codes, plus acknowledgement_version in the 202.
• Owner-list quota projection: quota_used, quota_limit and can_create.
  • can_create reflects both caps.
  • The projection is advisory, and limit_reached is authoritative.
• Operator doc (docs/operator-community-deletion.md): the acknowledgement version is a compile-time constant. Admission and the executor's claim/lease both filter on it. A version bump must keep replaying and executing old-version requests.

This follows on from #7830. The foundation PRs #7818, #7827 and #7830 are merged.

Testing

New tests:

• owner_delete_resubmission_reports_current_status_without_new_intent
  • A replay returns 202 submitted, including after membership purge.
  • Changing any field returns 409 deletion_request_conflict.
  • A non-operator gets 403.
  • A replay after abort returns 202 aborted.
  • No request rows are added.
• completed_owner_deletions_count_toward_lifetime_cap
  • After 20 created-then-deleted communities, the active count is 0 but can_create is false.
  • The next create and a transfer-in both return LimitReached.
• owner_quota_admits_only_under_active_and_lifetime_caps: a unit test.

Fellowship gate: PASS at 59375c00. The code review was clean. The E2E run covered authenticated KGoose → relay → the real drain executor. The later commits only change the operator doc.

Rollout

• Deploy order: this relay first, then KGoose squareup/cash-server#130634, then Web squareup/ext-builderbot-ui#241 and App Add recoverable hosted community deletion buzz-app#403.
• No shipped client ever called a receipt route, so removing it doesn't break any existing client.
• The quota changes have no deploy-order requirement.
• Keep owner deletion off until this relay and the drain executor are live.
• If you need to roll back, turn deletion off before rolling back the relay.
• Recreate any database that ran the earlier version of migration 0054. That only applies to disposable preview databases. Never apply this to a database holding real data. The earlier draft 0054 has a different checksum and index predicate.

Complexity

Net simpler:

• One route, its handler and a writer-routed get are removed. Recovery reuses the existing idempotent admission path.
• A single OwnerQuota::admits() backs create, transfer and the projection.
• The stale "clients fail closed / strict deployment order" doc section is replaced by the advisory quota contract.

[github-actions]

🔐 Codex Security Review

Status: review required for the current range.

The current range is 12dbb114aad72b89d17d6d1c668d8d4c3fdad2ae...e21151f47df20f396083702333bdf62179ef8cb4.
A new review must complete for this exact range. When manual authorization
is required, a Block organization member must comment exactly
@buzz-security-review e21151f47df20f396083702333bdf62179ef8cb4 to authorize a new review.
Any previous review applies only to its recorded range.

[TheSentinel454]

E2E: EXERCISED AND WORKS (scoped) — tested head 59375c0044a8bae31a0b5ab6cc7207d7000d1245 (tree 2b9fad8ecc4e3d9f7aed6383bbbdc8ed09caa497) on a freshly built local relay and buzz-admin with isolated PostgreSQL/Redis/Moto, NIP-98 signed operator HTTP, relay 127.0.0.1:39611. Evidence render (not a screenshot): https://buzz.block.builderlab.xyz/media/e3063a761d0f70b657f7116197e42bea689866327731c239f4d65d233487cf14.png

• Fixed UUID delete / identical replay: 202 submitted both times, same request and community. Real executor drain reached retention_pending (40 checkpoints, zero retries); identical HTTP replay then returned 202 retention_pending and the same IDs. Changed owner returned 409 deletion_request_conflict; changed acknowledgement version returned 400 unsupported_acknowledgement_version.
• Lifetime cap: 1 HTTP-created/executor-completed deletion plus 18 explicitly SQL-seeded completed tombstones yielded lifetime 19. List: can_create:true, quota_used:0; create Add just goose for one-command agent setup + fix API token auth #20: 200; create fix: resolve 10 E2E bugs + add desktop Playwright tests #21: 409 limit_reached: owner has reached the community limit; list: can_create:false, quota_used:1, quota_limit:5. With active quota raised to 25, list still false and fix: resolve 10 E2E bugs + add desktop Playwright tests #21 still 409.
• Removed /operator/communities/delete/receipt: signed POST 404, empty body; signed neighboring owner list on the same bound Host 200. Unauthenticated known delete route 401.

Source receipts: /home/bloxer/gimli-r7969-59375c/evidence/{SUMMARY.md,raw-http.jsonl,assertions.json,executor-inspect.json,db-quota-source-query.txt,final-audit.txt} on Blox workstation buzz-delete-admission-e2e. Fresh DB was empty before migration 0054; worktree clean and owned stack removed after the run. Scope limitations: synthetic operator asserted owner consent (not end-user Misk/Keycloak), NIP-FI off, Moto rather than cloud S3; 18 deletions were fixtures, not HTTP+executor runs. Deployment hold still applies: keep deletion disabled until relay+executor live, disable before relay rollback.

[wpfleger96]

🤖 Reviewed at e21151f4 against main @ 8519db15. Clear. I found nothing blocking.

Replay recovery looks right. NIP-98 verification, replay consumption and the operator allowlist all finish before the body is parsed or the UUID is looked up, so a non-operator can't learn anything about a request. admit_owner_request checks the ack version first, takes the per-UUID advisory lock, then compares host, owner origin, owner and version against the stored row. A matching resend returns the stored stage without needing surviving membership, and it never admits new work.

The quota invariant holds across all its writers, not just the ones the PR names. Create and transfer-in take the same per-recipient advisory lock around count and grant, so no two grants can both take the last slot. Owner deletion admission reserves a community that's already counted, and the UNION dedupes membership against intent, so admission doesn't change the count and doesn't need that lock. Purge keeps the reservation. Logical completion frees the active slot but keeps the lifetime count, and abort only happens before destruction, while membership is still live. Tenant role changes, invites, the admin CLI and the allowlist backfill can't grant owner. The startup/legacy provisioning exception was already there at base.

I also ran it live on the head binary with isolated PG/Redis/MinIO:

• A base 0001–0053 database upgraded to 0054 on boot, and the index is there.
• A resend after membership purge, after a real abort and after a full drain returned 202 with the current status. A changed host or owner got 409 deletion_request_conflict, an unsupported version got 400, an outsider got 403 and a reused NIP-98 proof got 401. Eight concurrent same-UUID submissions left one row.
• After 20 real create/archive/delete/drain cycles, create and transfer-in both returned limit_reached, with quota_used=0 and can_create=false.
• Mixed, create-only and transfer-only races at 19/20 each let exactly one through. Ten attempts at 20/20 let none through.
• Removing only the lifetime-cap conjunct made both new quota tests fail.

A few small things, none blocking:

• docs/operator-community-deletion.md:158 says any changed tuple under a known UUID gets 409. A changed ack version actually gets 400 unsupported_acknowledgement_version, which the next paragraph and the test both say. Worth adding that exception here and in the PR summary.
• Lifetime usage includes live ownership, so with the absolute cap no owner can hold more than 20 live communities, whatever BUZZ_MAX_COMMUNITIES_PER_OWNER says. The doc on max_communities_per_owner (relay_members.rs:572-573) still says operators can raise the cap. With an override above 20, the owner list reports a quota_limit the owner can never reach. I didn't find a deployment that sets it above 20, so this is just a doc fix (or a startup warning).
• The new lifecycle errors carry a stable code, but limit_reached on transfer and create is still only a message prefix (operator.rs:725, community_provisioning.rs:290). The doc lists limit_reached next to the coded errors, so clients may expect a code there too.
• The rollout note says to recreate any database that ran the earlier 0054. That fits disposable preview DBs, since the draft file has a different checksum and index predicate. I'd say so explicitly so nobody applies it to a database that holds real data.

CI at this head is green. The PostgreSQL Tests job ran 707/707 and Unit Tests ran all the new cases.