Probe route observer callbacks

docs/traffic-system-debrief.md

@@ -302,13 +302,49 @@ deactivates an old route ref and activates a new route ref. That is likely the
 common mappin state transition path for both journal/objective routes and
 custom/player pins.
 
+The newest controlled run confirms the queued route event timing:
+
+```text
+quest route click
+  -> JournalManager.TrackEntry from wrapper return RVA 0x26ac34e
+    -> MappinSystem route-event enqueue old route active=0
+    -> MappinSystem route-event enqueue new route active=1
+      -> 11-18 ms later: MappinRouteEvent::Handle
+        -> MappinSystem::RouteDeactivate(old route key)
+        -> MappinSystem::RouteActivate(new route key)
+          -> route observers at system + 0x280
+```
+
+The click-to-event delay matched the in-game behavior: the old GPS path
+disappears for a few frames, then the new path appears. That makes the route
+observer fanout the next most useful runtime layer to inspect.
+
+The activation/deactivation argument is not an object pointer. It is a 64-bit
+route key. Static disassembly of `0xaa6330` and `0x27abd7c` shows that key being
+looked up in the active-route map at `mappinSystem + 0x1a0`; the resulting map
+entry's `+0x08` field points at the actual route object/smart pointer passed to
+route observers.
+
+The first observer callback set seen at runtime is:
+
+```text
+observer vtable 0x14310e760: slot 0x48 -> 0xaa6610,  slot 0x50 -> 0x27b10c0
+observer vtable 0x143136050: slot 0x48 -> 0xaa6628,  slot 0x50 -> 0x295d4a0
+observer vtable 0x143121458: slot 0x48 -> 0xaa63e0,  slot 0x50 -> 0x286a85c
+```
+
+The installed probe now hooks those callbacks directly and logs the route entry,
+route object, route object vtable slots, and the route object's active byte at
+offset `0x84`.
+
 The most route-building-looking static candidate currently in this chain is
 `0x5625a4`, called once from the bridge at `0x5984ec`. The bridge resolves
 journal route ids through virtual journal-manager calls, collects several route
-descriptor/data pointers, and passes them to `0x5625a4`. The current RED4ext
-probe hooks this function with a 12-argument inferred signature to determine
-whether it builds GPS/path display data or merely updates UI-facing route
-metadata.
+descriptor/data pointers, and passes them to `0x5625a4`. Runtime evidence now
+shows this function firing in a dense load-time/minimap setup burst, not during
+later deliberate map-click route plotting. It may build cached route descriptors
+or GPS display metadata, but it is probably not the direct click-time solver
+entry point.
 
 ## Native False Positives