Cancel a pending wire transfer

Withdraws a payment declaration the TENANT itself opened and no longer wants reconciled — in the UI this is the "Cancel transfer" action shown only while a wire transfer sits in pending-manual-approval. The ledger entry moves to the terminal failed state with failureReason cancelled. It settles nothing and reverses nothing: a pending declaration was already granting no wallet credit and paying no invoice, so the terminal flip is the whole effect. It is the tenant-side twin of the operator's reject action, and deliberately uses a different failureReason so a withdrawal stays distinguishable from a money-never-arrived ruling. Validation: transaction must exist in the scope (else NOT_FOUND); the entry must be one the tenant declared — payment or wire-transfer-pending; a charge is a DEBT the platform is owed rather than the tenant's declaration and is refused with CONFLICT (flipping it failed would assert the charge never happened while the customer still owes it, and cancelling a commitment upfront would strand the commitment), as are the settling credit-applied and refund movements; current status must permit cancel — only pending-manual-approval (and pending) entries are cancellable, and cancelling a completed or failed entry maps to CONFLICT (re-cancelling an operator-rejected entry would overwrite its reason and launder the ruling); caller must hold contributor/admin/owner or billing role, otherwise FORBIDDEN. Guards are evaluated before any mutation, so a refusal leaves the entry and its invoice unchanged. Async & state: returns 202 with a SUCCEEDED Operation; the withdrawal is applied inline in one commit. State machine: pending-manual-approval (or pending) → terminal failed with failureReason cancelled. The change is emitted as a resource.updated SSE frame with kind billing.transaction patching status/failureReason. Errors: 401 unauthenticated; 403 insufficient role; 404 unknown scope/transaction; 409 CONFLICT when the entry type is not a tenant declaration or the current status does not permit cancel; 429 repeated cancel attempts rate-limited; 500 internal. Idempotency/Concurrency: This operation does not use Idempotency-Key; it may be omitted and a sent one is ignored. Each successful call returns a new already-SUCCEEDED Operation; repeating the cancel after it succeeded answers 409 CONFLICT because the entry is already failed (no longer awaiting resolution), so the withdrawal is never applied twice. This operation does not check If-Match; a sent one is ignored.