Reject an ARIMA period too short for its own orders

[mkzung]

Description

AutoRegressiveIntegratedMovingAverage checks period < Math.Max(arOrder, maOrder), which is weaker than what ComputeNextValue reads: arrayData[arOrder - 1] and _residuals[2 * maOrder], over a series DifferenceSeries shortens. The guard now asks for Math.Max(arOrder, 2 * maOrder + 1) + Math.Max(diffOrder, 0), and its message follows the wording Beta, Correlation and ValueAtRisk already use.

The clamp on diffOrder is there because nothing validates it as non-negative and DifferenceSeries runs only when it is positive, so a negative one costs no samples.

Related Issue

Closes #9757.

Motivation and Context

168 of the 534 order sets the old guard admits throw on the bar that fills the window, 127 at line 209 and 41 at line 201, before the indicator reports ready. HandleExceptions does not cover them: it wraps the two fitting steps, and both reads are in ComputeNextValue. With the change 366 of the 600 are admitted and none throws, so the same 168 are refused and nothing that works today is.

Requires Documentation Change

No.

How Has This Been Tested?

RejectsAPeriodTooShortForItsOrders takes six order sets, two of them with a negative diffOrder, and asserts both sides of the boundary and the exception text. The ARIMA fixture is 22 passed; reverting the guard fails four cases and reverting the clamp fails the other two.

IndicatorResetContractTests gives 1140 passed and 72 skipped on this branch and on master alike, which is where a stricter constructor would show since it builds every indicator at periods 1, 2 and 14. Every ARIMA in the repository is built at period 50, where nothing changes either way.