feat: invoice cloning, archival system, recipient authentication and reversible operations (#926, #927, #928, #929)

[Barbieple-Devstem]

Summary

Implements four features in the split contract, one commit per issue.

#926: Invoice cloning

• clone_invoice_partial(creator, source_id, recipient_indices, overrides) copies only the selected recipients, along with their amounts and per-recipient settings (swap tokens, split rules, priorities, payout caps).
• Before saving, every clone's recipients, amounts and deadline are checked (non-empty, matching lengths, positive amounts, no duplicate recipients, deadline in the future).
• Approval and progress state (signatures, approved, condition_met, released_stages) is reset on the clone. Per-recipient vectors that would no longer line up with the recipients are cleared instead of being copied out of alignment.
• Audit trail: a CloneRecord per clone (get_clone_record) and a clone history per source (get_clone_history), audit entries on both invoices, and a part_cln event.

#927: Invoice archival system

• An admin-set ArchivalPolicy controls run_archival_sweep. The sweep is permissionless, runs at most once per interval, and resumes from a stored cursor. It archives completed invoices older than archive_after_ledgers.
• restore_archived_invoice moves an archived invoice back to persistent storage. The restored invoice is then exempt from re-archival for a hold period.
• Cleanup: purge_archived_invoices (or auto_purge during sweeps) drops the payment shards of invoices archived for longer than retention_ledgers.
• Status tracking: an ArchivalRecord per invoice (get_archival_status) and ArchivalStats counters, kept up to date by lazy, explicit, batch and scheduled archival.

#928: Recipient authentication

• RecipientAuth record with the states Unverified, ChallengeIssued, Verified, Failed, Expired and Revoked.
• Creators opt an invoice in with set_recipient_auth_required and call issue_recipient_challenge with a bounded TTL. Each recipient then authorizes respond_recipient_challenge with sha256(challenge || recipient_xdr).
• Late responses mark the challenge Expired, and three wrong responses mark it Failed.
• _release refuses to pay out, and milestone payouts stay in escrow, until every recipient is verified.
• Every state change is written to a verification audit log (get_recipient_auth_log) and emitted as an rcp_auth event.

#929: Reversible operations

• reversible_update_deadline, reversible_update_amounts and reversible_cancel_invoice save an OperationSnapshot before changing the invoice.
• undo_operation restores the snapshot within the rollback window (admin-set through set_rollback_window, default 1 hour). The state machine is Recorded, then either Undone or Expired.
• Undo checks a hash of the state right after the operation, so it is rejected if the invoice has changed since. Each operation also writes audit entries and rv_rec / rv_undo events.

Closes #926
Closes #927
Closes #928
Closes #929

[drips-wave]

@Barbieple-Devstem Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits