Force live results store once holdings changes settle

[jhonabreul]

Description

The live trading result handler now monitors the order events, subscribing to the transaction handler's NewOrderEvent and tracking events with a fill status (OrderStatus.Filled or OrderStatus.PartiallyFilled) as holdings changes. Once the changes have settled for a configurable period — holdings-changed-store-delay, defaulting to 10 seconds — the update loop forces a store of the full live results instead of waiting for the next scheduled store (every 1 minute). The monitoring is encapsulated in a private nested HoldingsChangeMonitor class.

Repeated fills keep resetting the settle clock, and under continuous holdings churn the regular scheduled store still applies. Since the update loop runs on its own cadence, the effective worst-case latency is the settle delay plus one update pass. Holdings mutations that don't come from order fills (e.g. brokerage-side holdings syncs outside of orders) don't force stores and fall back to the scheduled store.

Related Issue

N/A

Motivation and Context

The full live results (including holdings) are only stored on a fixed 1-minute schedule, so consumers of the stored results can see holdings that are stale by up to a minute after fills. This change makes the stored results reflect the new holdings shortly after they settle.

Requires Documentation Change

The new holdings-changed-store-delay configuration could be documented.

How Has This Been Tested?

• New LiveTradingResultHandlerTests.HoldingsChangeForcesResultsStoreOnceSettled unit test running the real result handler thread and filling real orders through a BacktestingTransactionHandler/BacktestingBrokerage pair on a crypto security (market always open). It asserts that a store is forced only after the settle delay when a position is opened, increased, reduced and liquidated; that no store is forced without fills; and that order events without fills (a limit order submitted and canceled) don't force stores. Full LiveTradingResultHandlerTests fixture passes.
• Verified manually with a local live-paper deployment (FakeDataQueue + PaperBrokerage) running an algorithm that trades a crypto basket in batches every 30 seconds: every batch was followed by exactly one forced store 10-13 seconds after the fills (the settle delay plus up to one update pass), with no stores in between batches.

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>