test(security): chaos failure-injection lifecycle test (#468) + large-history treasury load test (#467)

[Tisan1000]

Closes #467. Closes #468.

What this delivers

#468 — chaos-style failure-injection test across the full settlement lifecycle

contracts/treasury/tests/lifecycle_chaos_test.rs

Replays issue #83's full end-to-end lifecycle
(create_invoice → mark_paid → propose_settlement → approve_settlement → compliance.is_allowed → execute_settlement → release_escrow) once per
cross-contract call boundary, deliberately forcing exactly that one boundary to
fail each time, parameterized by a FailurePoint enum rather than rewriting the
flow:

Injection	How it fails
ComplianceGate	merchant never allowed → is_allowed returns false
ExecuteThresholdNotMet	second approval skipped → execute_settlement → ThresholdNotMet
ExecuteTokenNotAllowed	non-empty allowlist without the settlement token → TokenNotAllowed
ExecuteSettlementOnHold	dispute raised first → execute_settlement → SettlementOnHold
ReleaseEscrow	invoice contract paused → release_escrow → ContractPaused
None	control — the happy path still completes

After every run it asserts the multi-contract system is left consistent,
whichever boundary failed:

1. Token conservation — treasury_balance + merchant_balance == minted total
2. All-or-nothing payout — merchant holds the whole amount or nothing
3. Merchant paid iff settlement reached Executed
4. Settlement status is always Pending / OnHold / Executed — never a limbo value
5. Invoice status is always Paid or Released — a failed release_escrow leaves it retryable, not wedged
6. Escrow released only when the settlement executed

The ReleaseEscrow case additionally proves recovery: unpause + retry completes
the lifecycle. No inconsistent state was found at any boundary.

#467 — large-scale load test: treasury with 1000+ historical settlements

contracts/treasury/tests/large_history_load_test.rs

#97 (settlement_pagination_test.rs) covers pagination correctness, but its
largest real corpus is 50 settlements. This builds a treasury with 1000+
settlements and records measured instruction costs for the key read/scan
entrypoints at that scale:

• get_pending_settlements_page stays correct at 1000+ entries — first page,
  deep mid-history page, window overrunning the end, start past the end,
  executed entries interspersed and skipped.
• Cost vs history size — whole-history scan for a 50-entry tail page,
  measured at 500 and 1000 settlements (~2x data, ~3x cost on the test
  host — linear scan with per-read overhead that itself grows slowly; a loose
  runaway-regression bound, plus the numbers are printed with --nocapture).
• resolve_dispute cost measured with 1000+ settlements as background load.

Finding (documented, not silently patched)

get_pending_settlements_page early-breaks once the requested page is full, so
a shallow page is cheap (~854K instr.) while a deep page over a 1000-entry
history costs ~O(start + limit) and approaches a full scan (~102M instr.,
~120× the shallow cost). Paginating a UI to the end of a large settlement
history is therefore not cheap — the same "cost scales with total accumulated
history" shape as the resolve_dispute concern in resolve_dispute_dos_test.rs.
page_scan_cost_grows_with_offset_depth pins the current behaviour.
Suggested follow-up: maintain a compacted pending-settlement index so
get_pending_settlements_page is O(limit) regardless of offset.

Prerequisite repair (first commit)

main did not compile — three of the four contract crates referenced
symbols that were never added or were dropped in a merge. The first commit
restores them so tests under contracts/treasury/tests/ can build:

• multisig: append TreasuryError::WithdrawalLimitExceeded = 35 (Add a treasury withdrawal-limit feature: maximum amount withdrawable per time window #455),
  InvalidSplitRatio = 36 (Add support for partial dispute resolution (splitting a disputed amount between claimant and counterparty) #456), ForceCancelNotAllowed = 37 (Add an emergency admin-override entrypoint to force-cancel a stuck settlement #457) —
  code already referenced all three.
• compliance: add DataKey::LastBulkAllow / LastBulkBlock (Add a rate-limiting mechanism to compliance's batch operations proportional to caller weight/role #454 bulk-op cooldown).
• treasury: fix DataKey::Balance(..) arity in deposit_one; add the missing
  enforce_withdrawal_limit helper; give resolve_dispute its trailing Ok(());
  complete resolve_dispute_split so a split resolution actually marks the
  dispute ResolvedSplit, records claimant_share_bps, emits
  dispute_resolved_split and releases the settlement hold (per its own doc
  comment) instead of leaving the settlement stuck OnHold.
• settlement-workflow: merge two conflicting enum DataKey definitions;
  re-add the dropped multisig dependency.
• test fallout: pin new discriminants in multisig_version_lock_test.rs; fix a
  prop_assert_eq! format-arg bug in multisig_quorum_property_test.rs.

Verification

• cargo build --workspace — passes
• cargo clippy --workspace -- -D warnings — passes
• cargo test -p comebackhere-treasury — passes (all 38 test files, incl. the
  two new ones: 12 tests), except the pre-existing failures below

Pre-existing breakage NOT addressed here (unrelated to #467/#468)

These were already broken on main (masked by the crates not compiling); left
for separate follow-ups:

1. contracts/treasury/tests/record_approval_duplicate_benchmark_test.rs (3 tests) — the test assumes propose_settlement doesn't pre-record the proposer's approval; the implementation does.
2. tests/tests/release_escrow_settlement_ordering_test.rs::settlement_proposed_before_release_still_executes_correctly_after — create_invoice(5_000_000, 5_100_000, …) is rejected with AmountPrecision.
3. contracts/settlement-workflow/tests/settlement_workflow_test.rs — needs a SettlementWorkflowError type + pause/unpause that were reverted out of the lib.
4. contracts/settlement-workflow/tests/divergent_admin_test.rs — not Soroban code (tokio/chrono/HashMap); has never compiled.
5. cargo fmt --all -- --check — 26 files carry pre-existing formatting drift.

🤖 Generated with Claude Code

[drips-wave]

@Tisan1000 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