Probe route observer callbacks

docs/red4ext-logging-shim.md

@@ -29,9 +29,15 @@ Current behavior:
 - Hooks the route handoff found from the journal listener bridge:
   `0x598250`, `0x13763d8`, `0xaa62d0`, `0xaa6330`, `0x27abd7c`, and
   `0x5625a4`.
-- Logs mappin route-event fields, active/deactive route refs, the mappin
+- Logs mappin route-event fields, active/deactive route keys, the mappin
   active-route map at `system + 0x1a0`, and the route observer list at
   `system + 0x280`.
+- Hooks the route observer callbacks reached by route activation/deactivation:
+  `0xaa6610`, `0xaa6628`, `0xaa63e0`, `0x27b10c0`, `0x295d4a0`, and
+  `0x286a85c`.
+- Logs the route entry pointer and route object pointer passed to those
+  observers, including route object vtable slots and common fields such as the
+  active byte at offset `0x84`.
 - Resolves the native mappin system when one of those paths fires, logs relevant
   vtable slot addresses, and temporarily hooks the route-adjacent slots.
 
@@ -48,6 +54,8 @@ Current route-probe focus:
 - mappin route-event enqueue: `0x13763d8`
 - mappin route-event handler: `0xaa62d0`
 - mappin route activate/deactivate: `0xaa6330`, `0x27abd7c`
+- mappin route observer callbacks: `0xaa6610`, `0xaa6628`, `0xaa63e0`,
+  `0x27b10c0`, `0x295d4a0`, `0x286a85c`
 - route-build candidate called by the bridge: `0x5625a4`
 
 Quest/objective pins did not fire the mappin tracking hooks in live tests. The
@@ -66,6 +74,22 @@ Most recent controlled test:
   dispatch to no-op `0x14a700`; the non-default callbacks above are the current
   drill-down targets.
 
+Newest controlled test:
+
+- User clock `01:05`: Continue on the main menu. The log saw
+  `GPSSystem/Tick`.
+- User clock `01:27`: Space to continue. The log saw automatic
+  `JournalManager.TrackEntry`, a dense `JournalRouteBridge` burst, and thirty
+  `RouteBuildCandidate 0x5625a4` calls. About 5.5 seconds later the mappin route
+  activation/deactivation functions fired.
+- User clock `01:52`: map open. Hovering icons produced the expected
+  `SetSelectedMappin` bursts.
+- Deliberate quest route clicks produced `JournalManager.TrackEntry`, route
+  event enqueue calls for old-route-off/new-route-on, and route event handler
+  calls roughly 11-18 ms later.
+- Custom pin routing used the separate custom-position mappin path, then the
+  shared route activate/deactivate helper.
+
 Build and install from the Fedora toolbox:
 
 ```bash

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