Prevent front-running of NAV price updates

[hpmaxi]

Priority

High — must be addressed in current sprint

User story / Problem statement

Currently, fulfill_epoch prices an epoch using the oracle's latest attested price without checking when that attestation arrived relative to when the epoch closed. If an epoch closes and no new attestation lands, a caller can immediately fulfill the epoch against an attestation that predates the close.

This allows an investor who anticipates an adverse revaluation (or observes an off-chain loss) to front-run the upcoming markdown by fulfilling pending redemptions at the stale, higher valuation before the attester posts the new report.

Expected outcome

An epoch cannot be fulfilled against an attestation accepted before the epoch closed, preventing stale-price front-running.

Acceptance criteria

• fulfill_epoch rejects fulfillment if the latest attestation timestamp is earlier than the epoch close timestamp.
• An attestation arriving at or after the epoch close timestamp permits fulfillment.
• Aligns with the notice period (Delay when a request becomes priceable #75), ensuring requests cannot be priced before their window elapses.
• A test proves fulfilling with a pre-close attestation is rejected.
• A test proves fulfilling succeeds once a post-close attestation arrives.

Technical notes

An epoch records its close timestamp at close_epoch. Fulfilment compares the oracle's latest record timestamp against that stored stamp. Alternatively, an explicit notice delay (#75) bounds when the post-close attestation may be consumed.

Refs: ARCHITECTURE §4.3 · findings: F-036