Car-sourced ambient reads high during pre-departure preconditioning

[zebraengine]

Observed

First full night of the TeslaMate ambient bridge (contrib/teslamate_ambient_bridge.py) running against a real install:

• While the car sat parked and idle, car-sourced ambient agreed with the Wall Connector's idle-handle proxy to a median difference of 0.0 °C (typically within ±0.5 °C) across ~9 hours at a steady 5-minute cadence.
• During a 46 A charge burst the handle sensor heat-soaked +13 °C while the car's thermometer held flat — the contamination the car source exists to bypass. Working as intended.
• The gap: the final sample before the car departed read ~2.3 °C above the (idle, trustworthy) handle proxy. Cabin preconditioning ahead of departure runs the HVAC hard, and the compressor/airflow warms the car's ambient sensor before any drive exists for the bridge's drive gates to react to.

The bridge already suppresses readings after a drive (heat-soaked sensor, --drive-cooldown-s), but it has no gate for the warm-up that happens before one.

Impact

Low but real: it is always the last reading before the bridge goes silent, so it lingers as "latest ambient" until the freshness window expires. A thermal fit that samples ambient in that window inherits the bias.

Possible fix

TeslaMate records climate state (positions.is_climate_on, preconditioning flags). Treat active climate like an in-progress drive: skip posting while climate is on, and optionally apply a short cooldown after it stops. Cheap to add to decide() — one more boolean gate, unit-testable the same way as the existing ones.

Notes

Once a fixed LAN sensor is present (Ecowitt gateway ingest, zebraengine/tesla-wall-connector#36), the car tier yields to it and this artifact stops mattering for installs that have one. Worth fixing anyway for car-only installs.