Hold the epoch lock while restoring from the WAL

[samliok]

Fixes a data race caught by CI in TestReplicatedNotarizationRestart: https://github.com/ava-labs/Simplex/actions/runs/31749442819/job/94611614678

Epoch.Start() runs the WAL restore without holding the epoch lock. Restoring can schedule the block building task and arm monitor and timeout callbacks, all of which acquire the lock and mutate epoch state from other goroutines while the restore is still reading it. In the failing test, the restarted node recovers a notarized round from the WAL, becomes leader of the next round mid-restore, and the scheduled block building task writes the rounds map in storeProposal while the restore path reads it in handleFinalizeVoteMessage.

Every internal handler assumes the lock is held: HandleMessage takes it before dispatching, but restoreFromWal called the same handlers without it. Start() now holds the lock until the restore completes and the epoch is ready to receive messages, so scheduled tasks block until then. broadcastReplicationSync acquires the lock itself and stays outside the locked region.