Buzzer feature: decentralized mesh building blocks for a lean automation engine

[Variour]

Summary

Party/game "buzzer" use case: at least 10 standalone devices, each with a button that plays a sound + light effect when pressed (optionally a persistent light state that only a central device can reset), with a central device recording press order — all over the mesh, without requiring any device to be on WiFi (control happens via the serial interface added in #436).

Rather than build this as one buzzer-specific feature, this was broken down into small, decentralized, reusable building blocks — deliberately steering toward these becoming the seed of a lean, Node-RED-like local automation engine (trigger → condition → action) rather than a one-off. See sub-issues for the individual pieces.

Design principles agreed for this story

• Fully decentralized: no central "rules server" role; every device evaluates its own bindings against broadcasts it receives. Mirrors the existing mesh philosophy (no single point of failure).
• Zero cost for devices not using the feature: a device with no configured bindings for an event type does nothing beyond receiving and discarding the broadcast — no separate enable/disable flag needed.
• Reuse over reinvention: builds on existing mechanisms (ActionExecutor/ButtonAction/ActionId fan-out, SoundDriver::scheduleFiles() from Add mesh-wide synchronized audio playback #394, group-based persistent light state, the shared HTTP/serial dispatch table from Add USB serial config mode (no WiFi/AP required) #436) instead of introducing parallel machinery.
• No premature generalization: the trigger/condition model intentionally only covers what today's concrete trigger (GenericEvent) needs. Other trigger types (button press, MQTT, ...) were discussed and don't fit the same condition shape (categorical vs. range vs. string-topic matching) — they get their own dedicated tables when actually built, rather than forcing one unified schema now.

Sub-issues

1. Generic mesh event message (GenericEventMsg)
2. Decentralized automation engine foundation (AutomationBinding/AutomationRule)
3. ActionId::PlaySound (builds on Add mesh-wide synchronized audio playback #394)
4. Persistent buzzer light state via dedicated groups (config-only, no new code)
5. Central event log + read endpoint (serial-reachable via Add USB serial config mode (no WiFi/AP required) #436)