ATM environment alarm system

Original wishlist item from the start of this project's Claude session: "More frequent measurements (frequency configurable) when above warning level to reduce lag and improve fire alarm abatement" plus "when more frequent measurements, the max values are recorded."

Now concretized as the natural payoff of the MQTT telemetry work (#61): while in Warning or Alarm state, increase measurement/publish frequency from the normal 5-minute cycle to every 1 minute or faster (exact cadence TBD - "every minute or maybe more often" per discussion), to reduce detection/reporting lag during a real event on the remote dashboard. Also capture the max (peak) value seen during the elevated-frequency window, not just each sampled point-in-time value, so a spike between samples isn't missed.

Depends on #61 for the delivery mechanism - the remote dashboard is what benefits from lower-lag data; local alarm/output logic already reacts to the sensor immediately regardless of logging cadence.

Open questions:

• Is faster-than-5-min SPS30 sampling sustainable for the duration of an alarm without excessive fan wear (see #29 Maintenance)?
• Exact target cadence during alarm, and whether it should itself be configurable as originally noted.