Prototype spatial GPS edge weights

docs/traffic-system-debrief.md

@@ -836,18 +836,30 @@ renamed to `EdgeWeightGPS.dll.disabled`.
 The main takeaway is still valuable, but narrower than first suspected:
 traffic lane flags are available in native route-side endpoint/candidate code,
 and `0x8d46cc` is an excellent landmark. It is not the city-wide graph-cost
-function. The safer cost target is `0x44f838`, or a data patch against the
-navigation `VAND` blobs it consumes. The next native work should avoid a full
-detour of `0x8d46cc` and instead look for either:
+function.
 
-- a `0x44f838` edge-cost hook that classifies graph edges by spatial proximity
-  to highway/arterial corridors
-- a navigation streamingsector patch that marks/weights selected `VAND` graph
-  points or edges
-- an inline patch around the vanilla constants/branches if the selector proves
-  sufficient
-- a safer result-stage rewrite only if upstream weighting cannot be patched
-  without desynchronizing the planner and renderer
+The current prototype therefore targets `0x44f838` instead. It generates a
+compact spatial grid from traffic lane polygons/flags and samples that grid
+from the search-state coordinates passed to the edge-cost callback. The first
+test multipliers are:
+
+```text
+highway  0.62
+road     1.00
+GPSOnly  1.20
+pavement 1.35
+unknown  1.05
+```
+
+This deliberately leaves VAND point class bits untouched. The materialization
+path branches on those bits after search, so rewriting them in data could alter
+route construction or instructions as well as cost.
+
+Runtime logs also show that long visible routes are decomposed into many local
+`0x44cc7c` route-producer searches. The tempting world-map caller
+`ret_rva=0x70aa22` mostly produced tiny connector searches in the resolver
+logs, so the first spatial test should patch edge cost across route-producer
+calls instead of gating only on that caller.
 
 ## Future Improvements
 
@@ -861,8 +873,10 @@ Better versions of this mod could:
   polygons and highway flags
 - extract the full Night City navigation streamingsector set into workspace
   storage and summarize it with `tools/analyze_vand_navigation.py`
-- implement a bounded `0x44f838` edge-cost hook or `VAND` data patch using that
-  join, rather than traffic `maxSpeed`
+- tune the generated spatial grid resolution and multipliers after in-game A/B
+  tests
+- add route-mode gating if the spatial edge-cost hook affects pedestrians,
+  autodrive, or other local navigation too broadly
 - inspect `GPSOnly` connector lanes if a later native trace proves they are
   consumed by the player GPS
 - build district-specific presets if a real data-cost surface is found