Append out of memory diagnostics to the algorithm runtime error message

[jhonabreul]

Description

When an algorithm dies with an OutOfMemoryException, the runtime error sent to the user is just:

Runtime Error: Exception of type 'System.OutOfMemoryException' was thrown.

This gives users (and LLMs assisting them) nothing to diagnose the failure with.

The change:

• Engine.HandleAlgorithmError now receives the algorithm instance and appends out-of-memory diagnostics to the runtime error message (user log, runtime error packet and API status) when applicable.
• Engine.TryGetOutOfMemoryErrorDetails detects an OutOfMemoryException runtime error and produces a compact message with:
  • The job's RAM allocation.
  • The algorithm's securities, subscriptions and universes counts — collected best-effort in a try/catch so diagnostics can never mask the original error, and skipped if the algorithm instance is not available.
  • The common causes and fixes, kept short on purpose: the message is primarily meant for LLM-assisted debugging, so it should convey cause and remediation without burning tokens.

Resulting message:

Runtime Error: Exception of type 'System.OutOfMemoryException' was thrown. The algorithm exhausted its 512MB of RAM. State: 480 securities, 960 subscriptions, 2 universes. Common causes: universe/subscription count too high for the allocated RAM; unbounded buffers such as rolling windows, consolidators or accumulated history results. Fixes: reduce universe size/subscriptions, use coarser resolutions, or bound buffers.

Related Issue

N/A

Motivation and Context

Out-of-memory failures are one of the hardest runtime errors for users to act on: the message carries no context about what the algorithm was doing. Surfacing the allocation, the subscription/universe footprint and the usual causes makes the error actionable for both users and LLM-based assistants.

Requires Documentation Change

No

How Has This Been Tested?

• Built the solution and ran the existing test suite locally; the change only appends details to the runtime error message for out-of-memory errors, with no behavioral impact otherwise.

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. N/A: message-only diagnostic change.
• All new and existing tests passed.
• My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>