[Event sessions] Apply and restore a channels-only event profile

[RCGV1]

Parent design: meshtastic/design#120 (event session addendum forthcoming)

Goal

Let a connected client place a radio into an event channel profile without factory-resetting the radio, then restore the user's pre-event channels after the radio returns to standard firmware.

Current boundary

factory_reset_config removes /prefs and recreates all defaults, including owner/config/device state/channels. It is not acceptable for event setup. begin_edit_settings / commit_edit_settings can defer persistence while a client sends set_channel, but there is no explicit event profile, channel-only clear command, durable restore marker, or end-to-end verification contract.

Firmware scope

• Define a versioned, capability-gated event-session operation for a channels-only replacement profile. It must validate the complete replacement before committing it; no partial persisted channel table.
• Preserve identity keys, owner, BLE bonds, node database, module config, and LoRa configuration unless an explicit, separately reviewed profile section permits a LoRa change.
• Ensure the resulting profile always contains one valid primary channel and remains locally administrable.
• Expose an authoritative completion/readback state suitable for clients to verify after reconnect. State must include the applied event/profile ID and a content digest, but never expose channel PSKs in status messages.
• Do not have a firmware image silently erase channels just because it booted. The authenticated, connected client must request and confirm the session transition.
• Preserve normal OTA behavior; this feature must not make standard firmware updates destructive.

Security and recovery

• The firmware must treat a profile as untrusted input: validate counts, roles, primary channel, keys, and supported settings before mutation.
• No backup of private channel material belongs in firmware logs or metadata. Clients own encrypted snapshots and restore only after device identity verification.
• An interrupted transition must leave either the prior complete channel table or the complete event table, never a persisted mix.

Acceptance / verification

• Unit tests: valid replacement; invalid/no-primary rejection; all disabled rejection; interrupted/failed commit; profile readback; standard OTA leaves channels unchanged.
• Hardware verification: one ESP32 OTA path and one nRF52 DFU path, with reconnect/readback after event setup and after return to standard firmware.
• Document the wire contract and compatibility behavior for old clients/firmware.

Related: Meshtastic-Android#3911, meshtastic/design#36.

[RCGV1]

Implementation research update: OTA preserves /prefs, so an on-device path can avoid any app dependency. Event firmware should use isolated /prefs/event-config.proto and /prefs/event-channels.proto; normal firmware continues reading /prefs/config.proto and /prefs/channels.proto, so flashing standard firmware naturally resumes the prior profile. On first event boot, seed the event config from normal identity/non-radio settings and replace only LoRa with the event build defaults; initialize event channels from the build defaults. Do not copy normal channels into event storage. The first firmware patch is now being built and tested against this model.

[RCGV1]

Closing this issue after scope clarification: the event-only workflow should reuse the existing QR add/replace semantics, not add a general client/firmware channel-profile protocol. The active implementation is firmware storage isolation in PR #11110 so normal firmware resumes the existing channel and LoRa files after an event OTA.