SimulatedNetwork 2.0

Production gossip is simply broadcast, plus the three-phase shadowgraph sync as gap repair and a fallen-behind detector.

The current SimulatedNetwork keeps all sent events and resends them when needed. This makes tests pass, but inadequately simulates the real behavior. There is no behind/ahead concept at all: no detection, no `BEHIND`-like signal, no recovery.

The goal of SimulatedNetwork 2.0 is to produce the same observable event streams and failure modes as broadcast+sync, but the goal is not to run the protocol.

Rough Design:

- One shared, append-only event log
- Per-receiver cursor into the log plus the existing scheduled-delivery queue
- Scheduling gate: connection up && receiver accepting. When the gate fails, the cursor stalls.
- Rewind on late failure. Scheduling is optimistic; if delivery fails, rewind the cursor to the earliest undelivered index.
- Catching up: drain events in log order, filtered by the receiver's current event window (simulates sync). The current behavior only filters on the the low end so as not to send any events that are ancient for the received. In the future, we must also filter at the high end as to not send any far future events for the receiver.
- Restart: reset the cursor to the start of the receiver's window
- Global log pruning by the minimum `expiredThreshold` over running, non-behind nodes

### Fallen Behind Detection & Reconnect
- Fallen-behind status is calculated by each node and reported to the SimulatedNetwork. Nodes determine this by comparing the event windows of peers to their own (forwarded by the Simulated Network).
- Fallen-behind nodes are not served events by the Simulated Network - they are provided a recent signed state to load.
- Falcon nodes will extract the consensus snapshot from the state and distribute it to the components (after they are cleared)
- Turtle nodes will need a custom reconnect module to keep it deterministic. This is probably not worth it, since we will not test production reconnect.

Start by locating SimulatedNetwork and reading its current event retention and scheduled-delivery behavior. Compare it with the rough design, then define completion by matching broadcast-plus-sync observable event streams, fallen-behind detection, reconnect behavior, and failure modes without running the production protocol.

Written by the indexing model from the issue text.