Add central event log + read endpoint for GenericEvent history

[Variour]

Part of #437. Depends on the "Add generic mesh event message (GenericEventMsg)" sibling issue for its input, and functionally on #436 (USB serial config mode) to be reachable without WiFi.

Summary

Whichever device is acting as the "central" (no formal device-role concept exists or is needed here — it's just whichever device someone points a laptop/serial cable at) records the order in which GenericEvent broadcasts arrive, so a buzzer session's press order can be read back.

Design

• Storage: fixed-size RAM ring buffer, oldest entries overwritten when full (no persistence across reboot — confirmed acceptable). Entry = resolved peer name (via existing PeerRegistry/PresenceMsg lookup by the sender MAC _onRecv already provides — no need to carry an ID in GenericEventMsg::payload itself) + eventType + payload + arrival order. Ordering is simply receipt order at this device — no clock sync needed (TimeSync is only second-granular and unnecessary here, since ESP-NOW broadcast latency between peers is low and consistent).
• Read API: GET /api/events?eventType=<string>, registered in the shared (ApiRequest, ApiResponse) dispatch table introduced by Add USB serial config mode (no WiFi/AP required) #436 — this makes it reachable over the serial connection automatically, with no serial-specific protocol work needed here.
• Live updates: push new entries over the existing WebSocket (data/index.html:3013) as a new t:'event' message type, alongside the existing t:'log'|'peers'|'groups', so a web UI viewer updates live instead of polling.

Open sizing question

Ring buffer capacity (e.g. 64 or 128 entries) still needs a concrete number — should be picked based on available RAM headroom when this is implemented.

Web UI

Read-only view: eventType filter, table of resolved name + payload + arrival order, updated live via the new WebSocket message.