Probe GPS packed handle resolver

docs/compaction-handoff.md

@@ -45,6 +45,7 @@ Active hooks:
   - `GPSQueryStatus 0xaa5704`
 - `GPSSearch 0x44f054`
 - `GPSRouteProducer 0x44cc7c`
+- `GPSResolveHandle 0x44e1a8`
 - `GPSEdgeCost 0x44f838`
 - filtered provider filter `0x44ff68`
 - base provider filter `0x450b08`
@@ -85,6 +86,7 @@ GPS pipeline landmarks:
 - query dispatch: `0x70a570`
 - route producer: `0x44cc7c`
 - local search loop: `0x44f054`
+- packed-handle resolver: `0x44e1a8`
 - edge cost: `0x44f838`
 - query result fetch: `0x7094b8`
 
@@ -117,6 +119,26 @@ Route result records:
 - The log's human wall timestamp has a millisecond rollover bug around second
   boundaries. Use the `+Nms` elapsed field for ordering and durations.
 
+Packed-handle resolver:
+
+- `0x44e1a8` decodes the packed route handle used by the search/materialization
+  side:
+  - low 20 bits: point index
+  - bits 20..47: segment index
+  - high bits: generation/check value
+- 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.
+- 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.
+
 ## Latest 23:08 Test Result
 
 The user clicked:
@@ -182,13 +204,18 @@ Inference:
 
 ## Next Work
 
-- Static disassembly around result-drain/producer RVAs `0x520783`,
-  `0x41be2c`, `0x41be94`, `0x70a42c`, and `0x8d20d4`.
-- The plausible patch point is upstream of result copy: find where search
-  output is converted to 0x28 route records or where candidate lanes are ranked
-  with enough lane-hash/resource context to prefer highway/major-road lanes.
-- Post-`0x7094b8` rewriting would likely only change displayed path records and
-  risks desynchronizing instructions from the real planner.
+- 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
+  `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
+  `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.
+- Avoid post-`0x7094b8` rewriting unless everything upstream fails; that would
+  likely only change displayed path records and risks desynchronizing
+  instructions from the real planner.
 
 ## Useful Commands
 

docs/red4ext-logging-shim.md

@@ -74,12 +74,17 @@ Active build note:
   `0x70a42c` submissions, `0x7094b8` result records, and local
   search/provider-cost stats.
 - It hooks `GPSSearch` (`0x44f054`), `GPSRouteProducer` (`0x44cc7c`),
-  `GPSEdgeCost` (`0x44f838`), and the two cost-provider filters
-  `0x44ff68`/`0x450b08`.
+  `GPSResolveHandle` (`0x44e1a8`), `GPSEdgeCost` (`0x44f838`), and the two
+  cost-provider filters `0x44ff68`/`0x450b08`.
 - The filter probe records pass/fail counts by point class and by the
   `point + 0x10` mask bits tested against provider masks at `+0x108`/`+0x10a`.
   This is meant to identify whether class/mask filtering, rather than the edge
   multiplier table, is dominating route choice.
+- The resolver probe logs selected packed-handle resolutions from the
+  search/materialization corridor. It decodes point index, segment index, and
+  generation bits, then dumps the resolved 0x68-byte segment record and
+  0x14-byte point record. The purpose is to see whether the edge-cost stage can
+  reach final lane hashes/resource-side road classes before a path is chosen.
 
 Current route-probe focus: