Correlate GPS route records with lane resources

docs/red4ext-logging-shim.md

@@ -224,6 +224,29 @@ Latest route-element decode:
   non-zero values appearing around the start segment.
 - `h20` has been zero in all captured full-map GPS result records.
 
+Route-record/resource correlation:
+
+- The `h00` field in the 0x28-byte route-result records matches
+  `worldTrafficLanePersistent.nodeRefHash`. In the current route logs, every
+  unique route handle checked matched a lane hash in the raw
+  `all.traffic_persistent` resource.
+- This lets us join emitted route segments back to resource-side lane metadata:
+  `flags`, `maxSpeed`, `length`, and `playerGPSInfo`.
+- The packed `u08` metadata is not a clean copy of resource-side lane flags.
+  Its low byte commonly appears as `2`, `3`, `4`, `5`, `8`, `9`, etc., while
+  the resource categories are bitflag bundles such as `Road`, `Highway`,
+  `GPSOnly`, `Intersection`, and `Pavement`.
+- A joined sample from `EdgeWeightGPS_cost_table_mild_2121.log` showed mixed
+  resource categories per low-byte class: class `2` was mostly pavement but
+  included highway lanes, class `8` was split between pavement and highway, and
+  class `1` was mostly road. This means the final route record's low byte is
+  useful metadata, but it is not by itself the class multiplier index from
+  `0x44f838`.
+- The next better lever is still the search-side cost provider table keyed by
+  `(*(routePoint + 0x13) & 0x3f)`. To tune it intelligently, we need either the
+  provider initialization site or a way to join search-side route points back to
+  `nodeRefHash`/lane flags before the edge cost is returned.
+
 Current static producer lead:
 
 - `0x70a908` packages the route endpoints and query settings, then calls