Use underlying tradable days for linked custom data bar count history

[AlexCatarino]

Description

Bar count history requests for custom data linked to an underlying security, e.g. BrainSentimentIndicator7Day on an equity, returned fewer data points than requested. Since the custom data market is always open, the request start time was computed by counting back calendar days, but the data only exists for days the underlying security trades, so weekends and holidays in the lookback window reduced the number of points returned.

HistoryRequestFactory.GetStartTimeAlgoTz now counts back the requested periods using the underlying exchange hours when the symbol is custom data with an underlying and its market is always open. Behavior is unchanged when the custom data type has specific market hours defined or the underlying market is also always open. Since the fix is in the factory, all bar count paths benefit: both History overloads from the issue, indicator warm up and algorithm warm up.

Also adds an IAlgorithm.GetExchangeHours extension that gets the exchange hours from the security if available, since the user can override them, else from the market hours database.

Related Issue

Closes #9598

Motivation and Context

Requesting N daily bars of linked custom data should return N data points.

Requires Documentation Change

No

How Has This Been Tested?

• New unit test asserting the bar count request start time for linked custom data counts back the underlying tradable days, skipping weekends and holidays
• New end to end test asserting a 10 daily bar history request for linked custom data returns exactly 10 data points (returned 6 before the fix)
• Full AlgorithmHistoryTests (334 tests) and warm up tests (105 tests) pass

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

🤖 Generated with Claude Code