Switch to GNSS immediately if it turns on mid-track

If Locate was already tracking via the browser-geolocation fallback
(GNSS was off when clicked) and GNSS then gets turned on via the
sidebar, it kept using the browser position until the button was
clicked again -- the browser's own (often less accurate) position had
no business still being used once the app's own receiver had a fix.

GnssControl#onEnabledChange (a small internal callback list) notifies
LocateControl the moment the sidebar toggle changes; if it's actively
tracking via the browser at that point, it stops that and jumps to
GNSS's position instead.

Caught a real bug while verifying this: the automatic handoff reused
the same jump-to-GNSS helper a deliberate click uses, which alerts if
GNSS has no fix yet -- but GNSS only just turned on and almost
certainly hasn't gotten its first poll response back yet at the exact
moment the handoff fires, so this popped a blocking window.alert()
(which halts the whole page until dismissed) on every single enable.
A test hung on exactly this before I noticed. Fixed with an
alertIfNoFix option, true only for the deliberate-click path.

Verified end to end (simulating the "already tracking" state directly
since headless geolocation isn't reliable enough to trust as the
trigger): toggling GNSS mid-track removes the blue browser marker,
shows the green GNSS one once its poll lands, and no dialog appears.

docs/architecture.adoc

@@ -261,6 +261,21 @@ as "the GNSS simulator, leaking somehow"). Uses MapLibre's own blue
 pulsing `.maplibregl-user-location-dot` (`maplibre-gl.css`) instead —
 the same look GeolocateControl itself had here before, and visually
 distinct from GNSS's green on purpose.
++
+GNSS turning on *while* the browser fallback is already mid-track
+switches over immediately rather than waiting for another click —
+`GnssControl#onEnabledChange` (a small internal callback list, not a
+full pub/sub system — nothing else needs one) notifies `LocateControl`
+the moment the sidebar toggle changes; if it was actively tracking via
+the browser at that point, it stops that and jumps to GNSS's position
+instead. That jump doesn't alert if GNSS has no fix yet (a
+`{ alertIfNoFix }` option on the shared jump-to-GNSS helper, `true`
+only for a deliberate click) — `GnssControl` only just turned on and
+almost certainly hasn't gotten its first poll response back yet at
+the exact moment this fires, so alerting here would pop a blocking
+dialog (window.alert() halts the whole page until dismissed) on every
+single enable; its own next poll shows/recenters once it actually has
+something, same as it would either way.
 
 === Debug inspector (Alt+click)