[kyscott18]

Fixes one of the two causes of the resync loop first reported in #137, which now fails seed 0x02 on main with no extra faults.

The bug:

1. A settlement must land within MAX_SETTLEMENT_DELAY (60s) of the timestamp it pins. The runtime pinned the timestamp of the block the watch was processing.
2. After a pause (the sim's 63s clock jumps) or slow providers, that block falls more than 60s behind the head.
3. Every settlement executed during catch-up, including a resync's replays, is then already too late. It reverts with InvalidSettlementTimestamp, triggers another resync, and the cycle repeats. No error is ever raised.

The fix:

• The watch already requests latest on every poll, and now carries the newest head's timestamp on each Added message.
• The runtime pins that timestamp in revm and in settlements.
• Block numbers stay as processed, so rebroadcast and stuck counting don't change.

Runs:

• Seed 0x02 stalls on main in this loop, and passes here.
• Seeds 0x01–0x20 (32 seeds) all pass.
• Unit tests pass.

Not fixed — a second cause, slow signing:

• With this patch, 0x600 on test(sim): take each transport down now and then; retry signing a settlement through it #137 (outages) and 0x27 on test(sim): add and remove credentials, and sign with them #143 (credentials) still stall.
• 0x27's plan with slowRate set to 0 passes, both with and without this patch. So its failure comes from slow requests, not stale pinning.
• My reading, not yet proven: settlements are signed one at a time, each with its own eth_fillTransaction. When requests take 5s timeouts or outages stall them, a backlog takes more than 60s to sign, so the tail misses the window it pinned at execution time.
• Fixing that is a design choice:
  • sign settlements locally, fetching nonce and fees once instead of per settlement;
  • or re-execute what can't be sent in time.
• I'd sign locally. I haven't built either.

🤖 Generated with Claude Code