Decode GPS route result records

docs/red4ext-logging-shim.md

@@ -168,9 +168,43 @@ Latest GPS-query finding:
   not rendered.
 - The current installed probe adds a read-only dump of suspected result-object
   fields around offsets `0x20` through `0x5f` on successful active-route
-  fetches, including first/last route point candidates from `outPath + 0x28`.
-  This is intended to identify whether the returned route is a raw solver path,
-  a smoothed draw path, or both.
+  fetches. The field at `outPath + 0x28` is confirmed to be a pointer-sized
+  route-result member with a count at `outPath + 0x30`, but live data does not
+  decode as plain `Vector3`/`Vector4` coordinates. The next probe treats it as
+  an internal route element array and dumps raw bytes instead of assuming a
+  float-vector layout.
+
+Latest route-result findings:
+
+- User clock `26:38`: Continue on the main menu.
+- User clock `27:01`: Space to continue, with the car in a different position
+  after a previous drive.
+- User clock `27:21`: map opened.
+- User clock `28:06`: normal route-click routine complete.
+- Same three quest destinations from the shifted start produced different
+  result counts: side job `12`, Sinnerman `23`, Claire's Garage `18`, and the
+  custom pin `17`.
+- Static disassembly of the `0x520783` result-drain caller shows `0x7094b8`
+  drains one 0x68-byte route result record at a time from an internal vector.
+- Inside that 0x68-byte record, `0x41c508` iterates the member at offset
+  `0x28` as an array of 8-byte pointers, using the dword at `+0x34` as the
+  live count. The dword at `+0x30` behaves like capacity or retained allocation
+  size; earlier logs that treated `+0x30` as the point count were reading the
+  right magnitude only while capacity and count matched.
+- The pointed objects appear to be route/lane segment objects rather than
+  coordinate vectors. The next probe logs the raw pointer array and selected
+  fields the engine reads from those pointed objects (`+0x68`, `+0x74`,
+  `+0x90`, and `+0x98`).
+
+Autodrive finding:
+
+- User clock `28:28` and `28:48`: enabling autodrive did not use the full
+  world-map GPS caller. It submitted repeated `0x70a42c` queries from return
+  RVA `0x8ed760`, with `query_fcc=4`, near-current vehicle positions, and
+  result fetches from return RVA `0x8ed7df`.
+- These autodrive queries appear to be short local vehicle navigation requests
+  using the same query service, separate from the full player GPS map route
+  caller at return RVA `0x8d20d4` with `query_fcc=5`.
 
 Build and install from the Fedora toolbox: