fix(generic): use Welford's algorithm for numerically stable rolling std

[Starlight143]

Fixes #714

Problem

rolling_std_1d_nb (vectorbt/generic/nb.py) computes the rolling variance from
cumulative sums using the naive two-pass formula:

var = (cumsum_sq_window - 2*mean*cumsum_window + n*mean**2) / (n - ddof)

This subtracts two large, nearly equal quantities whenever the input values have a
large offset relative to their variance (e.g. large price levels with small
fluctuations, as reported in #714). The subtraction discards most of the significant
digits and produces results that diverge sharply from pd.Series.rolling().std().

Fix

Replaced the cumsum-based formula with a single-pass Welford update, extended with a
matching "remove-point" update for the value leaving the sliding window (the standard
reverse of Welford's update). Welford's algorithm accumulates the mean and the sum of
squared deviations from the running mean directly, instead of accumulating and later
subtracting squared raw values, so it does not suffer from this cancellation.

The function signature, minp/ddof semantics, and NaN handling (values are skipped
when computing the mean/variance but still occupy their position in the fixed-size
sliding window) are all unchanged. rolling_std_nb (the 2-dim wrapper) is untouched
since it only calls rolling_std_1d_nb per column.

Numerical verification

Compared against pd.Series.rolling(window, min_periods=window).std(ddof=ddof) as the
reference, using the old and new implementations side by side:

Scenario	old max abs err	new max abs err
offset=1e8, window=4000 (issue #714 scenario)	9.153412e+00	1.062144e-09
offset=1e4, window=4000	5.743844e-05	4.350947e-13
typical price data (offset~100), window=20	1.162215e-09	5.641487e-12
typical price data (offset~100), window=20, ddof=1	1.192407e-09	5.788037e-12

For ordinary price-scale data the two implementations agree to within floating-point
noise (both around 1e-9 to 1e-12), so no existing golden values change. For the
large-offset case from the issue, the max absolute error drops from ~9.15 to ~1e-9.

Tests

Added test_rolling_std_numerical_stability to tests/test_generic.py, parametrized
over ddof in {0, 1}, covering:

• a large-offset (1e8), low-variance series against pandas.Series.rolling().std()
  (the scenario from For the same precision data, there is an accuracy error in the results. #714), and
• the same series with NaNs interspersed, to exercise the minp/NaN-count bookkeeping
  in the sliding window.

Test results on this branch (uv run --python .venv --no-sync pytest tests/):

• tests/test_generic.py -k rolling_std: 22 passed (20 pre-existing + 2 new)
• tests/test_generic.py (full file): 170 passed
• tests/test_indicators.py tests/test_engine.py tests/test_labels.py: 77 passed, 86
  skipped (skips are pre-existing, due to optional dependencies such as TA-Lib not
  being installed, unrelated to this change)
• Full suite tests/: 938 passed, 99 skipped, 0 failed

No existing test assertions or golden values needed to change.

[polakowo]

Thanks, the approach makes sense and fixes the reported case. Before merging, please:

• Change the validity check from window_len == ddof to window_len <= ddof; otherwise ddof > window_len can return zero instead of NaN.
• Do not clamp every negative M2 to zero. Reverse Welford can drift materially negative on long/high-offset streams. Please only clamp tiny round-off and handle or recompute an unstable state. Please add tests for both cases.
• Shorten the docstring and comments. A brief note that this uses Welford for numerical stability is enough.

[Starlight143]

Pushed. All three:

• window_len <= ddof now, so ddof > window returns NaN.
• Docstring trimmed to one line.
• M2 clamp: only zero it out for tiny round-off now. Material drift recomputes mean/M2 from scratch over the current window instead. Caught a bug in my own first pass while testing this — my drift threshold was scaled by mean², and mean is dominated by the offset, so at offset=1e8 that threshold was astronomically larger than any real M2 and the recompute branch never actually fired. Rescaled it off a decayed residual-magnitude estimate instead. Verified with an offset=1e14 stress case: blind-clamp wrongly reports exact zero for 1181/49971 points, the fixed version is 0.

Added tests for the ddof>window case and the drift case (checked against a fresh per-window np.std, not just pandas, since at that offset pandas' own rolling std isn't a reliable reference either).

[polakowo]

Thanks, merged.