Retry a failed payment (retired — always CONFLICT)

Retired. This action refuses every transaction with CONFLICT and is proposed for removal. It described a card re-charge — "initiated with the scope's default payment method", "Issuer declined — insufficient funds (code 51)", "never issues a second processor charge" — and the platform stores no cards and runs no payment processor, so there is nothing to re-attempt. paymentMethodId was already deprecated and ignored. What it did instead was settle the entry offline: a failed entry became completed and its linked invoice flipped PAID. That is settlement, which belongs to a platform Finance operator alone, and it was reachable by an ordinary tenant in two calls (cancel an invoice charge to failed, then retry it). Re-submitting a withdrawn payment is a different thing and does not need this action: submit a new one through the invoice pay endpoint, which records a fresh pending-manual-approval entry and leaves the withdrawn one intact for audit. Validation: transaction must exist in the scope (else NOT_FOUND, so an absent or cross-scope id is not distinguishable from a refused one); caller needs contributor/admin/owner or billing role, otherwise FORBIDDEN. Every resolvable transaction then answers CONFLICT regardless of type or status. Nothing is written under any code path. Async & state: none — the action never reaches a state transition. The 202 Operation response below is retained for schema compatibility and is no longer returned. Errors: 401 unauthenticated; 403 insufficient role; 404 unknown scope/transaction; 409 CONFLICT always. Idempotency/Concurrency: This operation does not use Idempotency-Key; it may be omitted and a sent one is ignored. Every call is refused (404 for an unknown entry, otherwise 409 CONFLICT) and nothing is written, so repeating it has no effect.