docs(wiki): document O(1) regression update and long-stream sum reseed (R2, R7)

Three indicator pages get a short follow-up paragraph that surfaces an
internal implementation detail the audit findings made user-visible:

- `Indicator-LinearRegression.md` gains a "Complexity" section explaining
  the O(1) update (precomputed `Σx`, `Σxx`; incrementally slid `Σy`,
  `Σxy` via the closed-form sliding identity), and the existing
  "Reset" bullet mentions the additional running accumulators. The same
  story applies to `LinRegSlope` and `LinRegAngle` (the page now links
  to both rather than repeating the derivation three times).

- `Indicator-Sma.md` and `Indicator-BollingerBands.md` mention the
  periodic reseed (`16 · period` updates) that caps floating-point
  drift on long-running streams. Amortised cost is still O(1) and the
  user-facing behaviour on benign inputs is unchanged.

No behavioural claim, no API claim, no example changes — just narrative
catching up with the implementation.

docs/wiki/indicators/moving-averages/Indicator-Sma.md

@@ -23,7 +23,12 @@ SMA_t = (1 / n) * Σ_{i=0}^{n-1} price_{t-i}
 
 where `n = period`. Maintained incrementally as `sum -= window.pop_front();
 sum += new_price; out = sum / n`, so `update` is O(1) regardless of
-`period`.
+`period`. To keep f64 rounding error bounded on long-running streams (where
+catastrophic cancellation between add/subtract pairs could otherwise
+accumulate), the running `sum` is reseeded from the live window every
+`16 · period` updates — still amortised O(1) (`O(period)` work amortised
+over `O(period)` updates), zero observable change on inputs that did not
+drift to begin with.
 
 ## Parameters