fix(pres_mgmt): config sync round 2 — save race, dead fields, launcher gate, version stamps

Four fixes found while tracing why Manager-saved Config page changes
(QR, POC column, etc.) weren't reliably reaching pres_mgmt_loc:

1. Config page save was a race, not deterministic. The save handler only
   called load_ae_obj_id__event() (SWR — returns stale Dexie cache
   immediately, refreshes in the background, not awaited) and assumed
   that "picked up the new config." It never called
   sync_config__event_pres_mgmt() itself. Now calls it directly with the
   just-saved draft, so the editing browser updates instantly with no
   race. Kept the load_ae_obj_id__event() call (default try_cache: true)
   for propagating to other browsers/tabs via Dexie — do not pass
   try_cache: false there, that skips the Dexie write entirely.

2. Removed the dead "Lock Config" Sync/Unlink toggle in the sign-in
   panel (e_app_access_type.svelte). It wrote to four fields
   ($ae_loc.lock_config/sync_local_config,
   pres_mgmt_loc.current.lock_config/sync_local_config) that are never
   read anywhere (confirmed via full-repo grep), and confusingly shared
   a name with the real, functional "Lock Config" checkbox on the Pres
   Mgmt Config page. Removed the button and the now-orphaned
   lock_config/sync_local_config fields from PresMgmtLocState.

3. show__launcher_link was never assigned by sync_config__event_pres_mgmt()
   — only its inverse hide__launcher_link was. The toggle button's
   `show__launcher_link || trusted_access` visibility gate (in 3 menu
   files) always collapsed to trusted-only, ignoring the admin's setting.
   Added the missing assignment.

4. AE_PRES_MGMT_LOC_VERSION was bumped to 2 this morning claiming it
   "forces a localStorage reset" — it didn't, because _check_and_wipe()
   was never wired up for ae_pres_mgmt_loc, and even if it had been, the
   store never wrote a __version field to compare. Fixed: the store's
   serializer now stamps __version, and store_versions.ts wires the
   check. Found and fixed the same bug already live in ae_leads_loc,
   except worse there — it was wiping leads users' local prefs on EVERY
   page load, not just once.

All logged in PROJECT__AE_Events_PressMgmt_Config_Cleanup.md.
svelte-check: 0 errors, 0 warnings.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

src/routes/events/[event_id]/(pres_mgmt)/pres_mgmt/config/+page.svelte

@@ -147,7 +147,23 @@ async function save() {
             fields: { mod_pres_mgmt_json: draft },
             log_lvl: 1
         });
-        // Reload the event so the sync function picks up the new config
+
+        // Sync this browser's pres_mgmt_loc immediately from the just-saved draft.
+        // WHY: load_ae_obj_id__event() below is SWR — it returns the stale Dexie
+        // cache right away and refreshes from the API in the background (fire and
+        // forget), so it cannot be relied on to update pres_mgmt_loc in time. Calling
+        // the sync function directly here makes the editor's own browser update
+        // deterministically, with no race against Dexie/liveQuery propagation.
+        events_func.sync_config__event_pres_mgmt({
+            pres_mgmt_cfg_remote: draft,
+            log_lvl: 1
+        });
+
+        // Also kick off the normal SWR reload (try_cache: true, the default) so
+        // Dexie gets the fresh record in the background — this is what lets OTHER
+        // browsers/tabs pick up the change next time they query Dexie. Do not pass
+        // try_cache: false here — that skips the Dexie write entirely (see
+        // GUIDE__SvelteKit2_Svelte5_DexieJS.md "try_cache: false Bug").
         await events_func.load_ae_obj_id__event({
             api_cfg: $ae_api,
             event_id: event_id,