`blocks-to-pces` : reject extraction windows that span a network freeze

## Problem

`replay-pces` invokes the consensus engine, which halts at the freeze round — `FreezeRoundController` sets `isFrozen = true` and no further rounds reach consensus. If a `blocks-to-pces` extraction covers an origin before a freeze and a target after it, the subsequent `replay-pces` run silently processes for hours before failing with a misleading "target round never reached consensus … increase DECISION_MARGIN_ROUNDS" error. The margin is not the problem; the freeze is.

A freeze-upgrade boundary also means the post-freeze blocks were produced by a different software version, so crossing it in a single replay would be wrong regardless of the halt.

## Proposed fix

Add a freeze-boundary check to `BlocksToPcesWorkflow.filterByRoundWindow`, which already scans every selected block to compute round spans. During that scan, also track the `PlatformState` singleton updates (`freezeTime`, `lastFrozenTime`, `latestFreezeRound`) and apply the same predicate the consensus engine uses (`isInFreezePeriod`: `roundConsensusTime >= freezeTime && freezeTime > lastFrozenTime`). If any round in `(origin, target]` triggers it, fail fast before writing any PCES:

> "Replay range crosses a network freeze at round F (freezeTime T). replay-pces halts at the freeze round and cannot reach a post-freeze target. Choose target ≤ F, or origin after the post-freeze restart."

Track the evolving `freezeTime`/`lastFrozenTime` across the window rather than reading once, so a `FREEZE_ABORT` (freezeTime cleared) within the window is correctly not flagged.

## Additionally

Update `ReplayPcesWorkflow.dumpCapturedState` to distinguish "freeze in range" from "insufficient decision margin" in its error message, so that if the pre-check is ever bypassed the failure is still diagnosable.