fix(precompute): correct counter resets in rate and increase

[milindsrivastava1997]

Summary

• Correct PromQL rate()/increase() counter-reset handling for single and keyed accumulators.
• Track reset corrections through explicit reset events and preserve them across merges and serialization.
• Use the explicit-event-only INC6 binary format.
• Remove V2/V5 compatibility branches and opaque reset metadata; old serialized payloads are intentionally rejected.
• Keep legacy asap-summary-ingest Arroyo templates out of scope.

Cutover

This PR intentionally breaks compatibility with existing increase-accumulator JSON and binary payloads. Existing precomputes must be discarded or regenerated before deploying the new format. The active Arroyo adapter also requires the current reset-aware fields.

Validation

• cargo test -p query_engine_rust — 582 tests passed.
• cargo clippy -p query_engine_rust --lib --tests -- -D warnings passed.
• Commit hooks passed formatting, check, clippy, and tests.

Fixes #476

[milindsrivastava1997]

Compared against #492 (older PR fixing the same issue, #476): both use the same reset-detection/correction algorithm and equivalent merge semantics. The one functional gap here is Prometheus boundary extrapolation (extrapolatedRate) — #492 implements it, this PR doesn't. Extrapolation covers the small gap between the window's actual start/end and the nearest real sample on each edge; without it, rate()/increase() here will be measured only between the observed samples, so results will drift slightly from real Prometheus as scrape interval grows relative to the query window. Reset-loss correctness itself is fixed correctly in both.