fix(alerts): replace corte_red heuristic with differential clamp + battery confirmation

[gnacho]

What

corte_red was firing on perfectly normal self-consumption: the old heuristic treated currentGridPower ≈ 0 as a proxy for "no grid", but that is just "not importing right now" — and a well-regulated Solis in self-consumption / peak-shaving holds grid flow at zero for minutes with the grid perfectly up. The audit log showed repeated false criticals every few minutes (8:37, 9:01, 9:07, 9:12, 9:32, 9:36, 9:42 on the day of the fix).

New signature

Replaces the "zero grid flow" guess with a differential signature based on the Tongou clamps on the main house board (already wired as ENTITIES.consRespaldo and ENTITIES.consNoRespaldada):

sinRed = fresco
  && gridMag < 0.05
  && noRespaldadaKw < 0.05         // circuito NO respaldado cae (sin red)
  && respaldoKw     > 0.03         // circuito RESPALDADO sigue (Solis+batería vía EPS)
  && live.batteryPower < -0.05     // batería DESCARGANDO (sin red, no se podría cargar)

In a real outage with the Solis EPS alive, the non-backed-up circuit drops to ~0 W while the backed-up circuit keeps running off the battery, and the battery must be discharging to sustain it. In a full blackout without EPS, both clamps go to 0 and this alert does not fire — inversor_offline covers that via anti-islanding.

Why the Fox is NOT used

The first version of this PR tried to use sensor.foxess_running_state (on-grid / off-grid) as the primary signal. Investigation against 8 months of recorder statistics showed it is unsafe: the 2025-07-12 incident had foxess_r_volt ≈ 0 V for ~20 hours while vivienda_medidor_power kept reading 200–1800 W the whole time. That was a foxess_modbus communication dropout, not a grid outage. Any signal based on the Fox can fire on Modbus/WiFi loss.

Battery-discharging clause (second commit)

The pure differential signature was still fragile: when the non-backed-up clamp itself drops to 0 W due to a Zigbee dropout, the signature looks identical to a real outage. Caught this on the first production run after deploying commit b2c177f — the clamp was stuck at 0 W with grid perfectly up (Fox on-grid, calentador_voltage 232 V, inverterOnline=1) and the battery charging from PV. Requiring the battery to be discharging filters this case: in a real outage with Solis EPS, the backed-up circuit is powered by the battery, so the battery cannot be charging.

Tests

server/test/push.test.js covers the new behavior matrix:

• self-consumption with gridPower=0 and both clamps > 0 → does not fire
• peak-shaving (battery discharging, gridPower=0, red present) → does not fire
• Fox Modbus dropout (2025-07-12 incident shape) → does not fire
• non-backed-up clamp Zigbee dropout + battery charging → does not fire
• full blackout without EPS → does not fire (covered by inversor_offline)
• real outage + EPS alive → fires after 3 ticks, recovers after 2

solar.computeLive now also exposes respaldoKw and noRespaldadaKw on the live snapshot.

Verified in production: 0 false criticals in the observed window after deploy, while the clamp was still in dropout. Closing #13.