Three findings from the multi-model review: - The multi-community loop returned on the first failing community, so one unreachable community PDS starved cleanup of every other community that admitted the post — each client retry re-failed on the same one while the healthy communities' acceptances dangled. Now every admission is attempted and the failures are errors.Join'd, so a healthy community is always cleaned up on the same pass and the retry converges the rest regardless of order. - A community credential failure (the community's stored token, not the author's session) surfaced through %w carrying pds.ErrUnauthorized/Forbidden, so the XRPC mapper would tell the AUTHOR to sign in again over a community-side outage — and hide that outage from 5xx alerting. Now severed via communityCredentialFailure, exactly as the legacy deleteCommunityPost path already does. - A committed withdrawal that reported no rev silently returned success with the admission row unstamped — the exact silent strand this change exists to kill. Now split: a genuine skip with no rev stays a graceful no-op; a committed result with no rev surfaces. Also corrects the loop comment to stop overstating forks as a live reality (§10.2's fork/import flow is not built; a post URI carries at most one standing acceptance today). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QDvRJ45k6E5KrBARDHUtiM