fix: Tuple GetPrs and GetRoc shims silently discard smaPeriods while bar overloads reject it

[DaveSkender]

Summary

The v3 shims disagree with themselves about smaPeriods. The same capability — "give me the indicator plus its SMA" — is a compile error on the bar-based overloads and a silent no-op on the tuple overloads, which merely warn and then discard the argument.

The unsafe form is the one that compiles.

Evidence

v2 populated PrsResult.PrsSma and RocResult.RocSma. Neither property exists in v3, so the value can never be honored; the guidance is to chain results.ToSma(smaPeriods) instead. Two overloads enforce that and two do not.

PRS — src/Obsolete.V3.Indicators.cs:686-694 vs :696-707:

Overload	Attribute	Effect of passing smaPeriods
GetPrs(IBar, IBar, int?, int?)	Obsolete(.., true) — error	cannot compile; message names the chained replacement
GetPrs(tuple, tuple, int, int)	Obsolete(.., false) — warning	compiles, argument silently discarded

ROC — :734-738 vs :740-749:

Overload	Attribute	Effect of passing smaPeriods
GetRoc(IBar, int, int)	Obsolete(.., true) — error	cannot compile
GetRoc(tuple, int, int?)	Obsolete(.., false) — warning	compiles, argument silently discarded

The tuple overloads' obsolete messages say only "Use 'ToPrs(..)' method. Tuple arguments were removed." and the ROC equivalent — neither mentions that smaPeriods is accepted and thrown away.

Impact

Lower severity than #2211 or #2212: the returned indicator values are correct, and only the requested SMA is missing. But it is a silent partial no-op. A v2 caller migrating tuple-based code keeps compiling, sees a warning about tuples, addresses that, and never learns their moving average stopped being computed — the result type simply has no field where it used to appear.

Resolution

Options, roughly in increasing cost:

1. Extend the tuple overloads' [Obsolete] messages to state that smaPeriods is ignored and direct callers to chain .ToSma(..). Cheapest; keeps compilation working.
2. Raise the tuple overloads to Obsolete(.., true) for the smaPeriods-bearing forms, matching the bar-based ones. Consistent, but turns a warning into a build break for code that currently compiles — a bigger step than fix: V3 GetKeltner shim narrows multiplier to int, breaking compilation of v2 code #2212, which only restores a call form.
3. Drop the parameter from the tuple signatures. Also a compile break, and loses the diagnostic opportunity.

Option 1 looks right for the 3.x line; option 2 or 3 would suit the wave that removes these shims.

Why it was not caught

Same as #2208, #2211, #2212: no test calls these shims and every one carries [ExcludeFromCodeCoverage]. A discarded parameter is additionally invisible to output comparison, since the values that are returned are correct.

Found while reviewing #2210.