fix: restore missing window sum in CR indicator

[NemeZZiZZ]

Problem

The CR indicator's own header documents the formula:

CR: SUM(MAX(0,HIGH-MID),N) / SUM(MAX(0,MID-LOW),N) * 100

but the implementation never sums over the window — it divides single-bar values:

if (preMidSubLow !== 0) {
  cr.cr = (highSubPreMid / preMidSubLow) * 100   // one bar, no SUM(...,N)
} else {
  cr.cr = 0                                      // every up bar → hard 0
}

Since preMidSubLow === 0 whenever low ≥ prevMid, every rising bar produces cr = 0. The leftover if (i >= params[0] - 1) delay and the fact that ma1..ma4 below are computed over params[1..4]-bar sums both indicate the window sum was lost.

Verified by execution (verbatim logic, Node): on a 500-bar random walk with N=26 the current implementation disagrees with the documented formula on 475 of 500 bars; on a gap-up bar it emits 0 where the formula gives 221.00.

Fix

Two rolling accumulators over params[0] bars — add the current bar's contribution, subtract the one leaving the window (the same pattern already used for ma1Sum..ma4Sum below), then cr = highSum / lowSum * 100. The MA thresholds and the i >= params[0] - 1 boundary are unchanged, so ma1..ma4 behave as before, just over correct CR values.

Verification

Patched calc vs the naive O(n·N) formula from the docstring, 500-bar random walk, N=26: max relative diff 0.0, 0/500 mismatches. Gap-up bar: 221.00 both. Degenerate N=1 reproduces the old single-bar ratio exactly. Bar-0 MID semantics (prevData ?? kLineData) unchanged.