Upload a wire-transfer receipt for manual approval

Uploads a SWIFT/EFT bank-transfer receipt for a wire-transfer transaction — both the initial "upload receipt · manual approval" step of the Pay-now wire flow and the "Upload a replacement receipt" control shown while a receipt is awaiting review. The file (PDF, PNG or JPEG) is sent as the RAW request body (not multipart); its display name comes from the fileName query parameter. The receipt's verification state is set to awaiting-review and the entry is (re-)queued for manual reconciliation by billing operations (SLA: 1 business day). A replacement upload supersedes the previous one and re-queues review. Validation: scope and transaction must exist and be visible (else NOT_FOUND); the transaction must still await resolution (pending / pending-manual-approval) and be a wire-transfer-pending or payment entry, and an existing receipt must not be verified — otherwise CONFLICT (a verified receipt is never re-opened); the body must be a non-empty PDF, PNG or JPEG (detected from its leading bytes, not from the name) of at most 10 MiB, otherwise VALIDATION_FAILED (field: file); the stored file name is sanitized (last path segment only, no path/HTML characters, at most 128 characters, extension matching the detected type); caller needs contributor/admin/owner or billing role, otherwise FORBIDDEN. Async & state: Conditional — the upload itself is accepted with 202 returning the stored WireReceipt in its transitional awaiting-review state; the downstream review transitions the receipt to terminal verified (transaction → completed) or rejection (transaction → failed). Review outcomes are emitted as resource.updated SSE frames with kind billing.transaction patching status and receipt.verification. Errors: 401 unauthenticated; 403 insufficient role; 404 unknown scope/transaction; 409 CONFLICT transaction state does not permit upload (already verified/settled); 422 wrong file type or oversize payload; 429 repeated uploads rate-limited; 500 object-store write failure. Idempotency/Concurrency: This operation does not use Idempotency-Key; it may be omitted and a sent one is ignored. The transaction is locked FOR UPDATE and holds one receipt, updated in place: a retried or repeated upload overwrites that receipt (file, name, size, awaiting-review) rather than attaching a second one or queuing a second review, and is refused with 409 CONFLICT once the receipt is verified.