Fix stale doc references and document the menu path

Addresses review feedback.

Four comments pointed at plan documents that were never committed
(plan-narrow-reboot-trigger.md, plan-decouple-nodedb-admin-saves.md), so the
rationale they cited was not discoverable. They now point at
docs/admin-config-save-gating.md, which is in-repo.

The doc listed the commit SHAs it described. All five had already been orphaned
by the rebases this branch has been through, exactly as predicted, so it cites
the PR instead. "Status: Implemented" also overstated things while hardware
validation is still outstanding.

The doc's biggest problem was that it had gone out of date within its own PR: it
described the on-device menus as an untouched code path that still reloads the
radio on any Config save, with per-site TODO markers. That stopped being true
when the menus moved onto applyConfigChange. Replaced with a section covering the
new entry point, the flags, why they are a flags enum rather than two bools, and
the saveToDisk equivalence that makes pairing the two calls a double write.

clod helped too

Author: NomDeTom

docs/admin-config-save-gating.md

@@ -1,9 +1,9 @@
 # AdminModule config-save side effects: radio-reload & reboot gating
 
-**Status:** Implemented
+**Status:** Implementation complete; hardware validation outstanding
 **Date:** 2026-07-23
 **Area:** `src/modules/AdminModule.cpp` (`handleSetConfig`, `saveChanges`), `src/mesh/MeshService.cpp` (`reloadConfig`), `src/mesh/NodeDB.h` (`SEGMENT_*`)
-**Commits:** `babeef08d` (radio-reload), `65c27f813` + `273fa8d0a` (segment docs / TODO markers), `71d711867` (reboot Tier 1), `cc9abdbbc` (reboot Tier 2)
+**Reference:** meshtastic/firmware#11181 (commit SHAs omitted - they do not survive rebase or squash merge)
 
 Saving a config over the phone/BLE used to do more than persist bytes: it could re-init the
 LoRa radio **and** reboot the device, on config that touched neither. This document records
@@ -161,21 +161,52 @@ is worth.
    Separating the few that plausibly don't need one (canned messages, ambient lighting,
    status message) needs a per-module audit - its own effort, not part of this work.
 
-5. **On-device menu `reloadConfig` sites** - 27 `reloadConfig(SEGMENT_CONFIG)` /
-   `reloadConfig(changes)` calls in `src/graphics/draw/MenuHandler.cpp` and
-   `src/graphics/niche/InkHUD/Applets/System/Menu/MenuApplet.cpp` still reload on any Config
-   save (they pass only `saveWhat`; the default `radioAffected=true` preserves this).
-   **Why untouched:** this work was scoped to the AdminModule (client admin-message) crash class.
-   The menu paths are a mix of genuinely-radio changes (region/preset) and incidental ones
-   (role, display units), run on the UI thread. Each is marked with a
-   `// TODO(radioAffected)` note (`audit` vs `radio-affecting`) for a future per-site pass.
+5. ~~**On-device menu `reloadConfig` sites**~~ - **now done, see "On-device menus" below.**
+   These were initially left alone as out of scope, then migrated in the same PR.
 
 For contrast, `set_channel` ([`:1445`](../src/modules/AdminModule.cpp#L1445)) and
 `restore_preferences` ([`:1911`](../src/modules/AdminModule.cpp#L1911)) also still reload -
 but that is _correct_, not conservative: both genuinely change LoRa/channel state.
 
 ---
 
+## On-device menus (`applyConfigChange`)
+
+Both UIs go through one entry point on `MeshService`, so a menu action states the same two
+decisions AdminModule does rather than inheriting defaults:
+
+```cpp
+void applyConfigChange(int saveWhat, uint8_t flags, int32_t rebootSeconds = DEFAULT_REBOOT_SECONDS);
+
+enum ConfigApplyFlags : uint8_t {
+    CONFIG_APPLY_NONE = 0,        // persist only
+    CONFIG_APPLY_RADIO = 1 << 0,  // region/preset/freq/channel/PSK - re-init the LoRa chip
+    CONFIG_APPLY_REBOOT = 1 << 1, // field only takes effect after a restart
+};
+```
+
+`flags` has no default: the point is that every call site says what it wants. A flags enum
+rather than two bools because `reboot` and `radioAffected` are both bools, sat in different
+positions across the helpers this replaced, and transposing them compiled silently. InkHUD's
+`applyConfigReload(changes, reboot)` took `reboot` exactly where `reloadConfig` and
+`saveChanges` take `radioAffected`.
+
+Notes for anyone extending this:
+
+- `reloadConfig(X, /*radioAffected=*/false)` is **exactly equivalent** to `saveToDisk(X)` - the
+  save is unconditional, outside the guard. So never pair them: that writes the file twice.
+- **AdminModule keeps using `saveChanges`**, not `applyConfigChange` directly. It owns the
+  edit-transaction deferral, without which a multi-field remote set writes flash per field.
+- Reboots go through `requestReboot()` (`src/main.h`). It carries no UI: BaseUI already renders
+  the notice at draw time from `rebootAtMsec`, while InkHUD's e-ink only draws when pushed and so
+  raises `notifyApplyingChanges()` explicitly.
+- `rebootSeconds` exists for one caller - InkHUD's wifi-recovery path uses a shorter delay than
+  `DEFAULT_REBOOT_SECONDS`.
+- UI-only state stays out of this: BaseUI `uiconfig` fields use `saveUIConfig()`, and InkHUD has
+  its own non-protobuf `Persistence::Settings` store. Neither is in the `/prefs` protobuf tree.
+
+---
+
 ## Verification
 
 Native coverage lives in `test/test_admin_radio/test_main.cpp`:
@@ -258,9 +289,8 @@ a cheap confidence test but not a gate.
 
 - To stop a config field from reloading the radio on an **AdminModule/client config save**: it
   already doesn't, unless it's `lora`. Do **not** widen `radioAffected` to non-LoRa config -
-  only `RadioInterface::reconfigure()` (which reads `config.lora`) consumes it. This does not
-  apply to the on-device menu `reloadConfig` sites (item 5 above), which still reload on any
-  Config save regardless of field - that is a separate, untouched code path.
+  only `RadioInterface::reconfigure()` (which reads `config.lora`) consumes it. The on-device
+  menus are now gated the same way, via `applyConfigChange` (see below).
 - To move a field off the reboot path: confirm it is consumed live (read from `config` at use
   time, no cached/driver state), add it to the live set in the relevant `handleSetConfig`
   case, and add a native case asserting no reboot on its change. For anything driver- or

src/modules/AdminModule.cpp

@@ -906,7 +906,7 @@ void AdminModule::handleSetConfig(const meshtastic_Config &c, bool fromOthers)
         // only them takes effect with no restart. Everything else - GPS driver mode/timing and GPIO pin
         // assignments - stays on the reboot path. Fails safe: neutralize the known-live fields in a copy,
         // then reboot if any *other* byte differs, so a newly-added PositionConfig field reboots until it
-        // is explicitly cleared as live here. See plan-narrow-reboot-trigger.
+        // is explicitly cleared as live here. See docs/admin-config-save-gating.md.
         {
             meshtastic_Config_PositionConfig live = config.position, incoming = c.payload_variant.position;
             incoming.position_broadcast_secs = live.position_broadcast_secs;

test/test_admin_radio/test_main.cpp

@@ -1519,7 +1519,7 @@ static void test_warn_license_transaction_coalescedToSingleMessage()
 // (which drives the live SX126x/RadioInterface reconfigure) when saveWhat includes
 // SEGMENT_CONFIG or SEGMENT_CHANNELS. Pure node-DB metadata saves - favorite, ignore,
 // mute - must skip that reconfigure entirely: it's the crash in the WisMesh Tag
-// favorite-node bug (see plan-decouple-nodedb-admin-saves.md). These tests watch
+// favorite-node bug (see docs/admin-config-save-gating.md). These tests watch
 // service->configChanged directly so a regression (someone widening the saveWhat mask,
 // or reordering the check) is caught even though these run outside an edit transaction.
 // -----------------------------------------------------------------------
@@ -2069,7 +2069,7 @@ static void test_moduleConfigTelemetryScreenFlags_liveInModuleConfig()
 //
 // position/network/bluetooth used to reboot on *every* set, including a client re-pushing
 // byte-identical config. A no-op set must now leave rebootAtMsec unset; any real change still
-// schedules the reboot exactly as before. See plan-narrow-reboot-trigger.md. reboot() only
+// schedules the reboot exactly as before. See docs/admin-config-save-gating.md. reboot() only
 // arms rebootAtMsec (it does not exit), so that is the signal we assert on.
 // -----------------------------------------------------------------------
 
@@ -2148,7 +2148,7 @@ static void test_setConfigBluetooth_realChange_schedulesReboot()
 //
 // A position change that touches only live-appliable fields (broadcast cadence, smart-position,
 // flags - read directly from config each cycle) must apply without a reboot. Boot-only fields
-// (GPS driver mode/timing, GPIO pins) still reboot. See plan-narrow-reboot-trigger.md.
+// (GPS driver mode/timing, GPIO pins) still reboot. See docs/admin-config-save-gating.md.
 // -----------------------------------------------------------------------
 
 static void test_setConfigPosition_liveFieldChange_doesNotReboot()