context: follow a middleware's next(), name a dispatch point's handlers, start at the producer

[swapnilpaliwal-sd]

context --source stopped at the places where a framework or a bus runs the next piece of code:

• Middleware next(): when a registered callback calls its own parameter, the flow now continues into what the same function registers after it on the same receiver, in the order written. Each such step shows the registration line. The graph already recorded these as callback_registered edges.
• Dispatch points: a call through a value whose candidates exceed the fan cap now lists the registered handlers instead of being dropped without a word. The fan counts only project, non-test candidates, so handlers registered in tests no longer hide the real ones.
• Producer side: when the question is phrased with publish/send/forward/emit and lands on the producing method, the flow starts at the method's caller. A caller joined only by name is shown as one labelled step.
• A nested function's step names the factory that made it. This is read from spans, so it works the same in TypeScript, where qualified names are flat.

Tests: new table-driven case javascript/flow-through-dispatch-points (5 checks plus 4 controls: another receiver, a terminal handler, route handlers in sequence, a question without a producing verb) and one TypeScript check folded into explain-flow. The new checks fail before the change and pass after. Suites: js 259/262 and ts 198/202; the remaining failures fail identically on the base. Python 274/275 and C# 202/204 also fail identically on the base or are outside context. Java 304/304, engine js 89/0. Product probes on the same build and graph: 48 → 49 of 70 (the proxy-flow probe is fixed), none regressed. Edges unchanged (8840): the change is query-only.