Trace GPS resolver during map queries

docs/compaction-handoff.md

@@ -4,12 +4,13 @@ Current date/time context: 2026-06-20/21, local timezone America/Chicago.
 
 ## Current Installed State
 
-- Latest installed probe commit: `54f014b Trace full GPS query results`.
+- Latest installed probe source: resolver-window probe. Use `git log -1
+  --oneline` for the exact checkpoint.
 - Installed RED4ext plugin:
   `Cyberpunk 2077/red4ext/plugins/EdgeWeightGPS/EdgeWeightGPS.dll`.
 - Installed build is read-only. It should not alter route behavior.
 - Latest archived test log:
-  `logs/EdgeWeightGPS_query_route_probe_2308.log`.
+  `logs/EdgeWeightGPS_resolve_handle_probe_4650.log`.
 - Game is cold as of the latest user message.
 
 ## New Toolbox Tools
@@ -129,15 +130,23 @@ Packed-handle resolver:
 - It resolves the handle into a 0x68-byte segment record and a 0x14-byte point
   record. The point record's `+0x13 & 0x3f` is the search-side class consumed by
   `0x44f838`.
-- The current probe logs selected resolver calls at return RVAs `0x44d26c`,
-  `0x44d304`, `0x44d99f`, `0x44d9cd`, `0x44db50`, `0x44db88`, and `0x44dd92`,
-  plus the first 64 successful calls as a guard against a bad static address
-  assumption. Logs are capped at 512 calls.
+- Live logging corrected the selected post-call return RVAs to:
+  - `0x44cb9e`: 0x38 intermediate-record builder. It writes packed handle,
+    `point+0x10` mask, `point+0x13` class, and coordinates from
+    `segment+0x18`.
+  - `0x44dd97`: geometry/materialization path. It walks the `segment+0x28`,
+    `segment+0x30`, and `segment+0x38` arrays for the resolved point.
+- The current probe opens a five-second resolver trace window before the
+  original `0x70a42c` submitter runs when the caller is `0x8d20d4` and
+  `query_fcc=5`. Inside that window it logs selected resolver callsites with
+  per-return-site caps instead of spending the whole budget on startup noise.
 - Each resolver line includes the decoded handle, segment/point pointers,
-  segment pointer fields `+0x08` through `+0x38`, raw segment bytes, and raw
-  point bytes. The goal is to determine whether the selected-path segment still
-  carries, or points to, the traffic lane hash/resource flags before the final
-  0x28 route records are emitted.
+  segment pointer fields `+0x08` through `+0x38`, raw segment bytes, raw point
+  bytes, raw `segment+0x08` metadata, the `segment+0x28` point-index record,
+  and small raw dumps from `segment+0x20`, `+0x30`, and `+0x38`. The goal is to
+  determine whether the selected-path segment still carries, or points to, the
+  traffic lane hash/resource flags before the final 0x28 route records are
+  emitted.
 
 ## Latest 23:08 Test Result
 
@@ -202,14 +211,60 @@ Inference:
   highway-heavy. Therefore final route-record `u08` low byte and search point
   `point+0x13` class are different domains.
 
+## Latest 46:50 Resolver Test Result
+
+Archived log:
+`logs/EdgeWeightGPS_resolve_handle_probe_4650.log`.
+
+User timing:
+
+- 46:50 Continue on main menu
+- 47:23 Space to continue
+- 47:35 map open
+- 47:43 side job
+- 47:51 Sinnerman
+- 47:57 Claire
+- 48:09 custom
+- 48:2x Aldecaldo camp
+- 48:57 game cold / `OnExit`
+
+Route summary:
+
+- routes=6, records=170, matched route records to lane hashes=170/170.
+- qid 1: startup/minimap, 18 records, 43 ms, 1216.5 pavement.
+- qid 2: side job, 12 records, 34 ms, 578.6 pavement.
+- qid 3: Sinnerman, 23 records, 45 ms, 897.4 pavement, 160.4 highway,
+  89.8 road.
+- qid 4: Claire, 18 records, 35 ms, 1216.5 pavement.
+- qid 5: custom, 19 records, 45 ms, 1006.3 pavement, 343.4 highway,
+  38.0 road.
+- qid 6: Aldecaldo, 80 records, 340 ms, 5853.5 road, 1492.9 highway,
+  1111.5 pavement, 24.6 gpsonly.
+
+Resolver sample findings:
+
+- The first resolver probe captured only the startup guard window because the
+  guessed return RVAs were post-call-off by a few bytes.
+- It still proved `GPSResolveHandle 0x44e1a8` attached successfully.
+- Actual resolver returns in the first 64 logged samples:
+  `0x44dd97:57`, `0x44cb9e:7`.
+- Resolver point classes in those samples: `4:60`, `5:4`.
+- The 0x68 segment header contains generation/counts/pointers; final
+  `nodeRefHash` values are not inline in those 0x68 bytes.
+- Static disassembly shows `segment+0x10` is the 20-byte point array,
+  `segment+0x18` is the coordinate array, and the materializer indexes
+  `segment+0x28` by `pointIndex*12`.
+
 ## Next Work
 
-- Install the resolver probe and run the usual map route routine.
-- Archive the plugin log as `logs/EdgeWeightGPS_resolve_handle_probe_<time>.log`.
-- Compare `GPSResolveHandle` handles/segment bytes against the final
+- Install the updated resolver-window probe and run the usual map route
+  routine.
+- Archive the plugin log as
+  `logs/EdgeWeightGPS_resolve_window_probe_<time>.log`.
+- Compare `GPSResolveHandle` pointer-target dumps against the final
   `GPSQueryResultFetch` route-record `h00` values joined to
   `work/raw-segment-json/all.traffic_persistent.json`.
-- If the resolver's 0x68 segment record or its pointer fields expose
+- If the resolver's pointer-target fields expose
   `worldTrafficLanePersistent.nodeRefHash` or equivalent road/highway flags,
   use that data inside `DetourGpsEdgeCost` to weight true resource-side
   highways/major roads. If not, follow the segment pointer fields statically.