Probe GPS query lifecycle

docs/red4ext-logging-shim.md

@@ -44,6 +44,18 @@ Current behavior:
   runtime type pointer at `.data` RVA `0x342f6a8`, logs the returned service
   object and slot `0x220`, then dynamically hooks that service `0x220` route
   lookup to log its route-id output handle.
+- The observer1 service branch was later identified as a false positive:
+  `0x287c44` returns the `JournalManager` object (`vtable 0x1430f0890`) and
+  the dynamic slot `0x220` resolves route IDs to readable journal/UI metadata
+  strings such as `internet`, `home`, `clubs`, and `arasaka`. It is now left in
+  the source but no longer attached in the active probe.
+- Hooks the GPS query lifecycle found from the `RunGPSQuery`/`UpdateGPSQuery`
+  native registration cluster:
+  `0x29bd128` (`RunGPSQuery` body), `0x29bd254` (`UpdateGPSQuery` body),
+  `0x70a42c` (shared query submitter), `0x70a570` (low-level query dispatch),
+  and `0x7094b8` (query result/path fetch).
+- Logs query endpoints, returned query IDs, shared submitter return RVAs, query
+  state fields, result-fetch success, and summarized path buffers/point counts.
 - Resolves the native mappin system when one of those paths fires, logs relevant
   vtable slot addresses, and temporarily hooks the route-adjacent slots.
 
@@ -63,8 +75,11 @@ Current route-probe focus:
 - mappin route observer callbacks: `0xaa6610`, `0xaa6628`, `0xaa63e0`,
   `0x27b10c0`, `0x295d4a0`, `0x286a85c`
 - observer1 service lookup and returned service route lookup:
-  `0x287c44`, dynamic service vtable slot `0x220`
+  `0x287c44`, dynamic service vtable slot `0x220` (disabled after being
+  classified as journal metadata)
 - route-build candidate called by the bridge: `0x5625a4`
+- GPS query lifecycle: `0x29bd128`, `0x29bd254`, `0x70a42c`, `0x70a570`,
+  `0x7094b8`
 
 Quest/objective pins did not fire the mappin tracking hooks in live tests. The
 REDscript decompile shows that those pins call `JournalManager.TrackEntry`
@@ -98,6 +113,27 @@ Newest controlled test:
 - Custom pin routing used the separate custom-position mappin path, then the
   shared route activate/deactivate helper.
 
+Latest observer1 probe result:
+
+- The `Observer1ServiceLookup` hook fired, but it proved observer1 is not route
+  solving. It returned the same `JournalManager` vtable seen in earlier journal
+  traces, and its slot `0x220` resolved numeric route IDs into journal/UI
+  category strings. That branch is closed as marker metadata.
+
+Current static lead:
+
+- `RunGPSQuery` and `UpdateGPSQuery` are registered native thunks at
+  `0x29bd5ac` and `0x29bd6c8`. Their deeper bodies are `0x29bd128` and
+  `0x29bd254`.
+- `RunGPSQuery` submits a query through a subsystem reached via an object field
+  at `+0x130`, returning a query ID or `-1`.
+- `UpdateGPSQuery` fetches a completed query result through `0x7094b8`, copies a
+  path point buffer, and writes the resulting point array for script/UI
+  consumption.
+- The shared submitter `0x70a42c` is also used by non-GPS navigation callers,
+  so return RVAs and query IDs are important for separating map GPS from traffic
+  or AI path requests.
+
 Build and install from the Fedora toolbox:
 
 ```bash