Fix the warm-up order analysis for Python algorithms and register the MarketOnClose too-late analysis

[jhonabreul]

Description

Two of the backtest results analyses never produce their findings, found while manually testing the in-run analysis stream (#9632) with a Python algorithm:

AlgorithmWarmingUpOrderResponseErrorAnalysis never matches Python algorithms. The engine formats the method names in the rejection message by algorithm language, so a Python algorithm produces:

This operation is not allowed in initialize or during warm up: OrderRequest.submit. Please move this code to the on_warmup_finished() method.

while the analysis expected the C# shape (... Please move this code to the OnWarmupFinished() method.). The case-insensitive match absorbs initialize, but the snake-cased on_warmup_finished can never contain OnWarmupFinished.

• Cause: the expected message fragments include the language-formatted method name.
• Fix: MessageAnalysis now supports an optional ExpectedMessagePattern regex that takes precedence over the text fragments, for messages with variable parts fragments cannot pin down. The warm-up analysis uses it to match the full message with both method-name spellings: (OnWarmupFinished|on_warmup_finished)\(\) method\.

MarketOnCloseOrderTooLateOrderResponseErrorAnalysis never fires for any algorithm. The rejection is logged with the exact expected text, but the analysis was never registered.

• Cause: the class was not included in ResultsAnalyzer.GetAnalyses().
• Fix: registered it with the other order-response error analyses.

Related Issue

N/A

Motivation and Context

These findings exist to surface order errors to the user (and LLM consumers) during and after a backtest; both were silently dead — one for every Python algorithm, the other for everyone.

Requires Documentation Change

N/A

How Has This Been Tested?

• New AlgorithmWarmingUpOrderResponseErrorAnalysisTests: the analysis matches both the C#- and the Python-formatted rejection message, and ignores unrelated messages.
• New MarketOnCloseOrderTooLateOrderResponseErrorAnalysisTests: the analysis matches the too-late rejection message, and ignores unrelated messages.
• ResultsAnalyzerTests.DefaultAnalysisSetIncludesTheMarketOnCloseOrderTooLateAnalysis: pins the registration in the default analysis set.
• All analyzer fixtures pass: 37 tests (ResultsAnalyzerTests, ResultsAnalyzerInRunTests, the two new fixtures).
• Manual verification through the Launcher with a packet-capturing messaging handler and a Python algorithm that submits an order during warm-up and a MarketOnClose order after the submission cut-off: before the fix neither finding ever appeared; after the fix the warm-up finding streams from the first in-run cycle (and mutes after the reporting cap like any other finding), and the MarketOnClose finding appears on the cycle following the rejection.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• Refactor (non-breaking change which improves implementation)
• Performance (non-breaking change which improves performance. Please add associated performance test and results)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Non-functional change (xml comments/documentation/etc)

Checklist:

• My code follows the code style of this project.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>