Document spatial cost inversion result

docs/compaction-handoff.md

@@ -88,16 +88,33 @@ Important caveat:
   `query_f78=10` and `query_ptr98_rva=0x8d76c4` mostly produces tiny connector
   searches, not the whole route. Do not gate the spatial patch only on that
   caller unless a later test proves it covers the desired route segment.
+- Live inversion test log:
+  `logs/EdgeWeightGPS_spatial_inversion_no_route_change_1845.log`.
+  The plugin reloaded highway-free weights at `+74681ms`
+  (`H=0.05`, all others `19.0`), then highway-expensive weights at `+235135ms`
+  (`H=19.0`, all others `0.05`). The four repeated map routes after the flip
+  produced final `GPSQueryResultFetch 0x7094b8` route records that were exactly
+  identical to the pre-flip route records:
+  route 3 vs 7, 4 vs 8, 5 vs 9, and 6 vs 10 all had identical lane handles and
+  packed metadata.
+- Practical conclusion: the spatial `0x44f838` detour is active and changes
+  many local route-producer edge costs, but it does not change the final
+  selected world-map route records for the tested player GPS routes. Treat this
+  hook as a local-search/connector lever, not the decisive full-route weighting
+  surface.
 
 ## Current Installed State
 
 - Installed RED4ext plugin is disabled:
   `Cyberpunk 2077/red4ext/plugins/EdgeWeightGPS/EdgeWeightGPS.dll.disabled`.
+- The latest tested DLL is also preserved disabled as:
+  `Cyberpunk 2077/red4ext/plugins/EdgeWeightGPS/EdgeWeightGPS.dd1423b.dll.disabled`.
 - There is no active `EdgeWeightGPS.dll` in the plugin directory.
-- Source defaults are currently safe/read-only. They should not alter route
-  behavior unless rebuilt with hook toggles changed.
+- Source defaults are currently read-only for route behavior again:
+  `kEnableGpsSpatialEdgeWeightPatch = false`. Focused final-route result tracing
+  remains available behind `kEnableGpsQueryResultTraceHooks = true`.
 - Latest archived test log:
-  `logs/EdgeWeightGPS_resolve_handle_probe_4650.log`.
+  `logs/EdgeWeightGPS_spatial_inversion_no_route_change_1845.log`.
 - Game is cold as of the latest user message.
 
 ## New Toolbox Tools
@@ -118,16 +135,17 @@ In `red4ext/EdgeWeightGPS/src/Main.cpp`:
 - `kEnableGpsProviderClassPatch = false`
 - `kEnableGpsProviderClassPatchTrace = false`
 - `kEnableGpsTraceHooks = true`
-- `kEnableGpsQueryLifecycleHooks = true`
+- `kEnableGpsQueryLifecycleHooks = false`
 - `kEnableGpsRouteJobLifecycleHooks = false`
 - `kEnableGpsRouteJobStartTrace = false`
+- `kEnableGpsQueryResultTraceHooks = true`
 - `kEnableGpsSpatialEdgeWeightPatch = false`
 - `kEnableGpsLocalSearchHooks = false`
 - `kEnableRouteUiTraceHooks = false`
 
-If rebuilt with the current defaults, active hooks are query/async lifecycle
-only. The spatial edge-cost patch requires `kEnableGpsSpatialEdgeWeightPatch =
-true`. The full local search/cost hooks below require
+If rebuilt with the current defaults, active hooks are focused map-route submit
+and final route-result fetch tracing only. The spatial edge-cost patch requires
+`kEnableGpsSpatialEdgeWeightPatch = true`. The full local search/cost hooks below require
 `kEnableGpsLocalSearchHooks = true`:
 
 - query lifecycle:
@@ -348,20 +366,18 @@ Resolver sample findings:
 
 ## Next Work
 
-- 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 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.
-- Avoid post-`0x7094b8` rewriting unless everything upstream fails; that would
-  likely only change displayed path records and risks desynchronizing
-  instructions from the real planner.
+- Pivot away from the spatial `0x44f838` cost detour for world-map routing.
+  It is proven active but does not alter final selected route records under
+  extreme inverse weights.
+- Statically disassemble the caller chain around the full map-route submit and
+  result path: `0x8d20d4`, `0x70a42c`, `0x70a570`, `0x7094b8`, `0x520783`,
+  and the async route-service cluster around `0x8d17d8` through `0x8d49xx`.
+- Identify where the final 0x28 route records are selected or copied before
+  `0x7094b8` returns them. The current evidence says that is closer to the real
+  full-route weighting/selection surface than the local `0x44cc7c` searches.
+- Avoid post-`0x7094b8` rewriting unless every upstream option fails; that would
+  likely only change displayed path records and risks desynchronizing route
+  instructions from the actual planner.
 
 ## Useful Commands