Pay redemptions in FIFO order by cumulative position

[hpmaxi]

Priority

High — must be addressed in current sprint

User story / Problem statement

fulfill_epoch refuses unless the vault covers the epoch's redemptions in full, so one large
redeemer blocks every small one in the same epoch, and an epoch stays unpriced until enough capital
has come back. The design pays claims as cash arrives, in order, without walking a queue.

Expected outcome

An epoch prices whether or not the cash is there. Claims pay in order of cumulative position as the
reserve covers them.

Acceptance criteria

• Fulfilment fixes the price and records the liability without requiring full coverage.
• A claim pays when the reserve covers everything ahead of it, and is refused otherwise with an
  error that says so.
• A claim in a later epoch waits until earlier epochs are covered. A test asserts it.
• Paying a later position never makes an earlier one unpayable. A test asserts it.
• Within one epoch, a claim is refused once the epoch's own share of cash is exhausted, so no
  payment is attempted against money that is not there.
• No entrypoint iterates over requests or epochs.

Technical notes

The ordering is by cumulative position, which needs a running total of liabilities struck and a
running total paid. The test that matters is an epoch that strikes more than the vault holds: the
first claimant is paid, the second waits, and the vault does not attempt a transfer it cannot make.

Depends on #72, which is what makes committed liabilities legible.

Refs: ARCHITECTURE §4.3 · invariants: I11, I12, I13

[hpmaxi]

Design Decision: Epoch-Level FIFO (Storage-Efficient)

Following architectural review against the current async-vault implementation and PR #80 specs:

1. Scope: Implementation remains in Pay redemptions in FIFO order by cumulative position #73 (Phase 2), keeping the current full-coverage check in PR Build the async vault: epochs, claims, treasury and roles #70 as an interim guard until this issue lands.
2. Granularity: Ordering operates at Epoch-Level FIFO rather than individual request-level sequence offsets:
   • Earlier fulfilled epochs must be fully covered before redemptions in subsequent epochs can be claimed.
   • Within a fulfilled epoch that is covered by available reserves, claimants in that epoch can claim.
   • This eliminates the need for additional storage fields (such as monotonic sequence numbers or cumulative liability offsets) on each individual RedeemRequest, keeping per-request storage minimal while strictly enforcing FIFO priority across epochs.