Fix Original consecutive-block penalty off-by-one + standardize run-length stats

[m4r1m0]

Summary

Fixes the same consecutive-block penalty off-by-one already fixed for the New path in #2, now in the Original path, plus standardizes the consecutive field to mean run length including the current block on every tab.

The bug

TIP-RFC-MT-0004 defines the penalty as m = 2^(r-1) where r is the block's position in the run (0 = fresh). The Original path applied it one position late:

• 2nd consecutive block paid 1x (expected 2x)
• 3rd consecutive block paid 2x (expected 4x)
• etc.

The README always described the correct behavior — the code was lagging by one.

Changes (js/simulation.js)

• runCompetition (Original): a fresh winner now starts a run of length 1 (else consecutiveCount = 1, was 0), so the block extending a run of length k pays 2^k = 2^(r-1). ✓
• buildResultObject: recorded multiplier 2^max(consecutive-1, 0) (was 2^consecutive), uncapped — matches what the Original path actually applied.
• runCompetitionWtema: same counter convention (reporting only; no penalty) so "Consecutive max" means the same thing on the WTEMA tab.
• countConsecutiveSameAlgo (baseline tab): run length including the current block; charts.js histogram relabeled to "Run of N" (a lone block is a run of 1).

The New path (runCompetitionSW, shipped in #2) already uses run-length semantics — no changes there.

Verification (VPS, Node v22, real blocks 294400–296521)

Harness T1–T7 all pass:

• T6: every Original-path multiplier equals 2^(run length - 1) uncapped; 2nd-in-a-row observed recording 2x; algo switch resets to 1.
• T7: baseline _consecutive equals the recomputed run length for all 2122 blocks.
• T1–T5 (LWMA, New-path TIP invariants, WTEMA, scenario generation) unchanged and green.