Validate option underlying subscription resolution

[pengpengyi92]

Description

Validate an option contract's effective resolution before adding its subscription. If the finest existing underlying subscription is coarser than the option contract resolution, AddOptionContract now throws an ArgumentException with guidance to add the underlying at the same or a finer resolution.

The validation uses the finest available underlying subscription, so algorithms with multiple underlying subscriptions continue to work when any subscription is sufficiently fine. It also uses UniverseSettings.Resolution when the option resolution argument is omitted.

Related Issue

Closes #9732.

Motivation and Context

LEAN computes option implied volatility and Greeks from the underlying's latest price. Previously, a minute option subscription could silently use a stale daily underlying price for the entire session. Failing fast prevents silently incorrect analytics without introducing a hidden subscription or changing data costs.

Requires Documentation Change

No. The exception explains the required subscription relationship.

How Has This Been Tested?

• Built Tests/QuantConnect.Tests.csproj in Release mode with .NET 10: 0 errors.
• Ran the six new resolution-validation cases in a .NET 10 + Python runtime container: 6 passed, 0 failed.
• Ran the complete AlgorithmAddDataTests fixture in the same minimal container: 54 passed. The only two failures were existing Python/Pandas tests because the minimal container intentionally does not include pandas; neither test exercises this change. Upstream CI uses the full quantconnect/lean:foundation environment.
• Ran git diff --check successfully.

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. (All new tests pass; two unrelated existing Python/Pandas tests require the upstream foundation image.)
• My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>

[jaredbroad]

Thanks @pengpengyi92 not a bad idea -- can you please reopen as a warning instead of fatal exception, shown once. You'll find similar patterns of "show once" errors in LEAN. Minute resolution might be the best people have, especially for indexes which don't update that frequently.