docs: clarify config save behavior for GPS position updates

Author: NomDeTom

docs/admin-config-save-gating.md

@@ -234,9 +234,8 @@ keypair, favorite/unfavorite a node.
 ### 2. Position live-apply - expanding the Tier-2 live set (outstanding)
 
 The only reason to touch a node for the _reboot_ work: decide whether the GPS-timing fields
-left on the reboot path (`gps_mode`, `gps_enabled`, `gps_update_interval`, `gps_attempt_time`
-
-- item 3 above) can actually apply live and be reclassified.
+left on the reboot path (`gps_mode`, `gps_enabled`, `gps_update_interval`, `gps_attempt_time` -
+item 3 above) can actually apply live and be reclassified.
 
 For each candidate field, one at a time, on a GPS-equipped node: change only that field (over
 serial, as above) and observe.
@@ -257,9 +256,11 @@ a cheap confidence test but not a gate.
 
 ## Extending this safely
 
-- To stop a config field from reloading the radio: 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.
+- 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.
 - 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/mesh/MeshService.h

@@ -169,7 +169,6 @@ class MeshService
      * @param radioAffected when false, suppresses the live LoRa reconfigure even if saveWhat
      *        includes SEGMENT_CONFIG/SEGMENT_CHANNELS; the save-to-disk always happens. Defaults
      *        to true so callers that only pass saveWhat keep the historical bitmask behavior.
-     * @return true if client devices should be sent a new set of radio configs
      */
     void reloadConfig(int saveWhat = SEGMENT_CONFIG | SEGMENT_MODULECONFIG | SEGMENT_DEVICESTATE | SEGMENT_CHANNELS,
                       bool radioAffected = true);

src/modules/AdminModule.cpp

@@ -922,11 +922,12 @@ void AdminModule::handleSetConfig(const meshtastic_Config &c, bool fromOthers)
             c.payload_variant.position.gps_mode != meshtastic_Config_PositionConfig_GpsMode_ENABLED &&
             config.position.fixed_position == false && c.payload_variant.position.fixed_position == false) {
             nodeDB->clearLocalPosition();
-            saveChanges(SEGMENT_NODEDATABASE | SEGMENT_CONFIG, false, /*radioAffected=*/false);
+            // SEGMENT_CONFIG is deliberately omitted here: config.position hasn't been updated to the
+            // incoming value yet, so saving it now would persist stale data. The final saveChanges()
+            // below re-saves SEGMENT_CONFIG once config.position is current.
+            saveChanges(SEGMENT_NODEDATABASE, false);
         }
         config.position = c.payload_variant.position;
-
-        // Save nodedb as well in case we got a fixed position packet
         break;
     } // case meshtastic_Config_position_tag
     case meshtastic_Config_power_tag: