Probe observer1 route service lookup

docs/red4ext-logging-shim.md

@@ -40,6 +40,10 @@ Current behavior:
   active byte at offset `0x84`, the service lookup key at offset `0x8c`, and
   the runtime observer1 service-owner path used before its vtable `0x220`
   lookup.
+- Hooks observer1's generic service lookup at `0x287c44`, filters it to the
+  runtime type pointer at `.data` RVA `0x342f6a8`, logs the returned service
+  object and slot `0x220`, then dynamically hooks that service `0x220` route
+  lookup to log its route-id output handle.
 - Resolves the native mappin system when one of those paths fires, logs relevant
   vtable slot addresses, and temporarily hooks the route-adjacent slots.
 
@@ -58,6 +62,8 @@ Current route-probe focus:
 - mappin route activate/deactivate: `0xaa6330`, `0x27abd7c`
 - mappin route observer callbacks: `0xaa6610`, `0xaa6628`, `0xaa63e0`,
   `0x27b10c0`, `0x295d4a0`, `0x286a85c`
+- observer1 service lookup and returned service route lookup:
+  `0x287c44`, dynamic service vtable slot `0x220`
 - route-build candidate called by the bridge: `0x5625a4`
 
 Quest/objective pins did not fire the mappin tracking hooks in live tests. The

docs/traffic-system-debrief.md

@@ -365,6 +365,26 @@ handles/strings under its inner object at offsets around `+0x180`, `+0x1a0`,
 `routeObject + 0x8c` so the next runtime test can tell whether observer1 is
 crossing into GPS/path computation or just updating presentation state.
 
+The `07:22:14` controlled run confirmed observer1 is in the deliberate route
+click window, not just load-time setup. The three quest route clicks produced
+the expected sequence:
+
+```text
+JournalManager.TrackEntry
+MappinSystem.RouteEventEnqueue old active=0 / new active=1
+MappinSystem.RouteDeactivate old route key
+MappinSystem.RouteActivate new route key
+RouteObserver1 deactivate/activate with the matching routeObject + 0x8c route id
+```
+
+The observer1 service-owner object was stable across those calls
+(`serviceOwner` vtable `0x142b74ea8`, slot `0x08` target `0x140287c44`).
+Static disassembly of `0x140287c44` shows a generic type-to-service lookup, so
+the next probe hooks that function, filters on the runtime type pointer at
+`0x342f6a8`, logs the returned service object, and dynamically hooks the
+returned service's vtable slot `0x220`. That slot is the immediate next native
+call after the lookup and receives the route id from `routeObject + 0x8c`.
+
 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