Probe route observer service lookup

docs/traffic-system-debrief.md

@@ -337,6 +337,34 @@ 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 first observer-object run separated three route-object vtable families:
+
+```text
+vtable 0x142b31138: quest/objective route objects, key at +0x40
+vtable 0x142af1510: quest/objective route objects, key at +0x40
+vtable 0x142b30e20: custom/player pin route objects, key at +0x40
+```
+
+`RouteActivate` and `RouteDeactivate` really do flip the route object's active
+byte at `+0x84`. The observer callbacks receive the same route entry after that
+flip.
+
+Static disassembly of observer0 (`0xaa6610 -> 0xaa6678`) shows it consuming
+route-object virtuals at `+0x1a8`, `+0x188`, `+0x140`, and `+0x198`.
+`+0x198` returns a route enum from a nested descriptor; `+0x188` returns a
+descriptor payload pointer; and `+0x140` is a route-family-specific boolean.
+That observer stores derived route state into buckets under the observer object,
+choosing one bucket only when the enum is `0x8e`.
+
+Static disassembly of observer1 (`0xaa6628`) is now the highest-value
+downstream branch. It resolves a route object, then calls a generic system
+getter with a runtime type/global at `.data` RVA `0x342f6a8`, calls the returned
+service's vtable slot `0x220` with `routeObject + 0x8c`, and stores generated
+handles/strings under its inner object at offsets around `+0x180`, `+0x1a0`,
+`+0x1c0`, and `+0x1e0`. The current probe logs that service-owner path and
+`routeObject + 0x8c` so the next runtime test can tell whether observer1 is
+crossing into GPS/path computation or just updating presentation state.
+
 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