Decode GPS result point array

docs/red4ext-logging-shim.md

@@ -155,9 +155,12 @@ Latest GPS-query finding:
 - `GPSQueryResultFetch 0x7094b8` returning `1` is the route-solve completion
   signal. The caller at return RVA `0x52069c` starts handling a completed
   result, then the caller at return RVA `0x520783` drains result records.
-  The visible route record currently appears as a packed point/count pair in
-  the object passed as `outPath`: the deliberate routes produced `11`, `16`,
-  `15`, and `14` point-like counts.
+  The visible route record appears in the object passed as `outPath`: offset
+  `0x30` is a packed point count (`N/N` on the first drain record, then `N`),
+  and offset `0x28` looks like the route point array pointer. The deliberate
+  routes produced the familiar `11`, `16`, `15`, and `14` point-like counts in
+  the 2026-06-20 19:03 run, and `11`, `16`, `15`, `11` in the 19:16 map
+  routine where the custom pin was different.
 - Static disassembly confirms `0xaa5704` takes `(manager, queryId)` and returns
   a small status code; one caller checks for value `1`. Runtime logging shows
   this is HUD/display lifecycle polling rather than solve completion: it polls
@@ -165,8 +168,9 @@ 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. This is intended to identify whether the returned route is a raw
-  solver path, a smoothed draw path, or both.
+  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.
 
 Build and install from the Fedora toolbox: