Record stream management for full automatic restart

### Problem

Suppose a node begins `REPLAYING_EVENTS` using a saved state with consensus time `X`, where `X` is in the middle of a 2-second period `[T, T + 2s)`.

It is possible that the record stream file for the `[T, T + 2s)` period was never written to disk.

This means replay will skip all record stream items with consensus times in the `[T, X)` range.

### Solution

We have at least two possible solutions:
1. Keep the last 2s of consensus **transactions** in state (we already have the last 180s of **records**); this would let us easily reconstruct the full record stream file for the `[T, T + 2s)` period in the above scenario.
2. Enhance platform to signal (e.g. in `DualState`) which state will be saved to disk; and then update Services to always treat a saved state's `lastHandledConsensusTime` as a record stream file boundary. (So in the above example, we would be guaranteed to instead write a file for the `[T, X]` period; and can safely start a new record file when `REPLAYING_EVENTS`.)

### Alternatives

_No response_

Start by tracing the REPLAYING_EVENTS flow and how record stream files relate to saved state, then inspect the DualState and Services concepts mentioned in the issue. Compare the two proposed approaches around lastHandledConsensusTime and define completion as preventing replay from skipping the [T, X) range.

Written by the indexing model from the issue text.