Run past consolidators before scheduled events

[Kevin-Li-2025]

Description

Fixes #8649.

AlgorithmManager.Run currently scans past scheduled events before scanning past consolidators. When the engine catches up over a period with no data, a scheduled event can run before a due consolidator scan updates registered indicators, so the scheduled callback observes stale indicator state.

This moves the past consolidator scan ahead of ScanPastEvents while preserving the same performance tracking blocks. The added regression test runs AlgorithmManager with a single time-pulse slice and asserts that the realtime handler only scans past scheduled events after a due consolidator scan has run.

Related

Related to #5595.

Testing

DOTNET_CLI_HOME=/private/tmp/dotnet-cli-home DOTNET_ROOT=/private/tmp/dotnet10 PATH=/private/tmp/dotnet10:$PATH dotnet test Tests/QuantConnect.Tests.csproj --filter "FullyQualifiedName~ScheduledEventsRunAfterPastConsolidators" --logger "console;verbosity=minimal"

Result: passed, 1 test.

[Kevin-Li-2025]

Follow-up with the intended behavior this PR is trying to lock down: when a scheduled event and a consolidator are both due at the same frontier time, the consolidator should be advanced first so the scheduled event observes the latest completed bar, not stale state from the previous frontier.

The regression test covers that ordering directly. I kept the change localized to the time-slice ordering path rather than changing scheduled event semantics more broadly. Happy to adjust if there is a more appropriate Lean convention for this case.