escrow has no mutual-consent early cancellation path

[abayomicornelius]

Problem

escrow::get_escrow(env: Env, escrow_id: u64) (escrow/src/lib.rs lines 197-199) is the only query function in the entire contract. There is no way to enumerate escrows by depositor or beneficiary — a wallet/frontend wanting to show "your active escrows" has no on-chain query path and must instead rely entirely on replaying emit_escrow_created/emit_escrow_released/emit_escrow_refunded events off-chain and reconstructing state itself, with no contract-side index to fall back on or cross-check against.

Why it matters

Every other contract in this repo with per-user or per-token state provides at least one useful enumeration/summary query beyond raw single-key lookup: fee_collector::get_total_collected (aggregate per token), token_bridge::get_wrapped_balance (per holder), stellar_send::get_payment_record (per sender+sequence, and sequence numbers are discoverable via KEY_SEQ). escrow has no equivalent per-depositor or per-beneficiary index, only opaque, sequential escrow_ids with no relationship exposed between an address and the ids relevant to it.

Proposed fix

Add a persistent secondary index, e.g. (KEY_DEPOSITOR_ESCROWS, depositor) → Vec<u64> and (KEY_BENEFICIARY_ESCROWS, beneficiary) → Vec<u64>, appended to in create_escrow and exposed via new get_escrows_by_depositor(depositor: Address) -> Vec<u64> / get_escrows_by_beneficiary(beneficiary: Address) -> Vec<u64> queries.

Edge cases

• An address that's the depositor or beneficiary of a very large number of escrows over time could make the Vec<u64> index itself expensive to read/write (grows unboundedly) — may need to cap how many ids are retained, or paginate, or accept the tradeoff since escrow counts per address are typically small relative to, say, payment records.
• Storage cost: two new persistent entries updated on every create_escrow call adds write amplification — worth benchmarking against the alternative of leaving this entirely to off-chain event indexing (which is what most Soroban dApps do in practice) before committing to on-chain indexes; this is a real design tradeoff, though scoped narrowly enough here (unlike the "spike" issues in this batch) that a reasonable default (cap + document the tradeoff) is enough to implement without further open-ended research.

Testing strategy

Add test_get_escrows_by_depositor_returns_all_created, test_get_escrows_by_beneficiary_returns_all_created, and a test confirming the indexes stay correct across multiple create_escrow calls from the same depositor to different beneficiaries and vice versa.