Automatic warm-up for registered indicators, scalar Update error and not-ready Current warning

[jhonabreul]

Description

Indicator warm-up automation improvements, closing the gaps that force algorithms into manual history-replay ceremony:

• Settings.AutomaticIndicatorWarmUp now also covers RegisterIndicator, including consolidator registrations:
  • History is replayed through a temporary consolidator mirroring the registered one (same input type and period), so the indicator gets the same bars it will receive live. The live consolidator is untouched.
  • The consolidator's span comes from a new ConsolidatorBase.Period virtual, implemented by the time-based consolidators.
  • Non time-based consolidators (Renko, range, count) are skipped with a one-time debug message; indicators without a WarmUpPeriod are skipped silently.
  • Internal helper registrations go through a private RegisterIndicatorCore, so their warm-up behavior is unchanged.
• indicator.update(bar.close) — the common scalar-update misuse from Python — now throws a prescriptive NotSupportedException naming the valid update forms, instead of a cryptic binding error. (A decimal overload is not viable: it makes existing Update(IndicatorDataPoint) call sites ambiguous.)
• Reading indicator.Current while !IsReady logs a one-time warning naming samples received vs needed. Internal reads by composite indicators (e.g. MACD reading its EMAs) are suppressed, and the check self-disables once ready.
• Verified the automatic warm-up path already picks the correct bar type per asset class (quote bars for forex/CFD) — pinned with tests, no code change.

Behavioral notes:

• The AutomaticIndicatorWarmUp default stays false; flipping it is a separate policy decision.
• Candlestick pattern helpers now warm up under the setting too, consistent with other helpers.
• MarketHourAwareConsolidator.Period changed from protected TimeSpan to public override TimeSpan?.

Deferred: a per-call register_indicator(..., warm_up=True) flag and a generalized warm-up helper (existing WarmUpIndicator overloads already cover the indicator case).

Related Issue

N/A

Motivation and Context

Manual warm-up ceremony is a large source of boilerplate (~10–35 lines per algorithm), and manual replay is a recurring crash class (self.history[TradeBar](forex_pair, ...) on quote-only forex; rsi.update(bar.close) binding errors). Making register_indicator respect the existing setting deletes the idiom instead of documenting it.

Requires Documentation Change

Yes: Settings.AutomaticIndicatorWarmUp now also covers RegisterIndicator-registered indicators; the indicator Update docs can mention the scalar-update error.

How Has This Been Tested?

• New AlgorithmIndicatorsTests cases (red before, green after): consolidator registration warms iff the setting is on; selector and resolution overloads; Renko skipped without throwing; forex indicators warm from quote data.
• New IndicatorTests cases: prescriptive scalar-update error for data-point and bar indicators, including through the real Python binding; not-ready Current warning fires once, not when ready, and not for internal composite reads.
• New AutomaticIndicatorWarmupConsolidatorRegressionAlgorithm (C# + Python): green with identical statistics. Existing warm-up regression algorithms updated and green.
• Suites: full Tests.Algorithm (12,715), Tests.Indicators (1,493), Tests.Python (1,323), all consolidator fixtures (234) — 0 failures.

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>