feat(core): detect a stuck meter register during an active transaction

[sepehr-safari]

Split out of #108. A session whose cumulative energy register never advances is a
real fault, and no current rule catches it.

METER_VALUE_ANOMALY fires only on negative or decreasing cumulative readings.
A flat series is neither, so a meter reporting the same value for an entire
transaction passes clean. Checked against current main: an all-zero series
across three MeterValues inside a transaction produces no failures at all.

Proposal

A new detection rule, working name METER_VALUE_STUCK, reporting when a
cumulative energy register does not advance across an active transaction.

Open questions, worth settling before implementation

What counts as stuck. Same value across N consecutive readings, no change
across a minimum elapsed time, or no change between meterStart and
meterStop. Time based is more meaningful than count based, since the sampling
interval varies by station.

Legitimate flatlines. A session can sit at SuspendedEV or SuspendedEVSE
for long stretches and report an unchanging register perfectly correctly.
Flagging those would be a false positive of exactly the kind #127 and #128 were.
The rule probably needs connector status, which points at the per-connector model
arriving with v0.5.0.

Zero versus non-zero. A register stuck at 0 for a whole transaction is a
stronger signal than one stuck at 45000, which may just be a full battery. Worth
deciding whether those are one rule, two rules, or one rule with two severities.

Severity. Probably warning, in line with METER_VALUE_ANOMALY.

Scope

Engine work rather than a good-first-issue. It needs a judgement call about false
positives and most likely the per-connector session model.

Per #140, a detection rule ships with a scenario exercising it in the same pull
request. #108 already covers the negative side, a legitimately flat meter that
must stay clean, so this issue owns the positive case.