每个 session/follow 都注册一个 { global: true } 监听器：global 绕过作用域过滤，于是每个被派发的事件都要先选中全部跟随流

① 每事件成本随跟随流数线性增长，且作用域过滤被绕过

用随包真实的 Cordis 派发同一形态的 session/event：N=0 时每次派发 1,135.9 ns，N=64 时 104,921.9 ns。线性拟合斜率 1,621 ns / 监听器 / 事件，r² = 1.0000。决定性的第二列：selected_per_emit 在每一档都恰好等于 N（1/2/4/8/16/32/64）——如果这些 global 监听器经过作用域过滤，被选中的数量应该只与「真正关心这个会话的流数」相关，而不是等于全部。

② 代价付在每个事件上，而不只是被跟随的那个会话

注册点是 dsh-api-session-controller：每个 follow 流注册 3 个 global 监听器（session/event、session/created 无条件；agent/assistant-stream 在 request.assistantStream === true 时）。而 global 的语义就是「不按作用域筛」，所以进程内任何会话派发事件时，这 3×F 个回调都会被选中一遍，再各自在回调体里按 id 丢掉。总量因此约 O(会话数 × 跟随流数)。

Title: Every `session/follow` stream registers a { global: true } listener, so each
       dispatched event costs O(open follow streams) process-wide - linear fan-out that
       bypasses scope filtering

Summary
-------
A DSH Host is one Node process that serves every Session. When a browser follows a Session, the
host opens a `session/follow` stream and registers listeners with the option `{ global: true }`.
"Global" means the listener BYPASSES Cordis's per-context scope filter: it is selected for EVERY
event dispatched anywhere in the process, and only then does its own body discard the event with
`if (session.id !== target) return;`.

The cost of selecting listeners is therefore paid per dispatched event, in proportion to the number
of open follow streams - and every Session's events pay it, not just the followed one. Across a
process the total is roughly O(sessions x follow streams).

I measured the real primitive, not a model of it: the benchmark below drives the shipped Cordis
`Context` / `events.dispatch()` through the same call shape `dsh-session` uses on every append.

Why this matters
----------------
A single Host already runs every Session and every in-process subagent on one JavaScript main
thread. This adds a per-event cost that grows with how many sessions the user has open, and it is
paid by every event in the process - including events of sessions nobody is watching. At 64 open
follow streams a single dispatched event costs about 105 microseconds of pure listener selection,
before any listener does any work.

Environment
-----------
  DSH        0.1.5-rc.1 (offline bundle, @deepseek-ai/*)
  Cordis     4.0.2            (the event bus that dispatches session events)
  Node       v24.16.0
  Command    node ops/dsh/upstream-issue-follow-listener-fanout/follow-fanout-bench.mjs

Evidence (measured)
-------------------
  N	ns_per_emit	selected_per_emit
  0	1135.9	0.00
  1	2892.6	1.00
  2	4393.2	2.00
  4	7632.1	4.00
  8	14236.6	8.00
  16	27438.4	16.00
  32	53143.4	32.00
  64	104921.9	64.00

  Linear fit over N: slope = 1621 ns per listener per emit, r2 = 1.0000.

Two things this table establishes by itself:

  * `selected_per_emit` equals N exactly. If global listeners were scope-filtered, the number
    selected would stay near the number of listeners that actually care. It does not: every global
    listener is selected for every event, and the filtering happens afterwards, inside the callback.
  * The marginal cost is ~1.6 microseconds per listener per event, and it is additive: at 64 open
    follow streams one dispatched event costs ~105 microseconds regardless of which Session it
    belongs to.

Code references (0.1.5-rc.1, shipped lib/)
-----------------------------------------
  dsh-api-session-controller/lib/index.js:1419  this.ctx.on("session/event", (session, event) => {
  dsh-api-session-controller/lib/index.js:1420      if (session.id !== target) return;
  dsh-api-session-controller/lib/index.js:1426  }, { global: true });
  dsh-api-session-controller/lib/index.js:1427  const disposeCreated = this.ctx.on("session/created", ...
  dsh-api-session-controller/lib/index.js:1435  }, { global: true });
  dsh-api-session-controller/lib/index.js:1436  ... this.ctx.on("agent/assistant-stream", ({ agent, frame }) => {
  dsh-api-session-controller/lib/index.js:1444  }, { global: true });

    -> three per-follow registrations, two of them unconditional (:1427/:1435 is registered for
       every follow stream; :1436 is conditional on request.assistantStream === true).

  dsh-session/lib/index.js:963   function collectSessionCallbacks(ctx, args) { return [...ctx.events.dispatch("emit", args)]; }
  dsh-session/lib/index.js:1195  callbacks = collectSessionCallbacks(entry.emitCtx, [entry.carrier, "session/event", ...callbackArgs]);
  dsh-session/lib/index.js:1202  if (callbacks !== void 0 && entry !== void 0) invokeContainedSessionObservers(...)

    -> the append path resolves the FULL listener set for every single event, then invokes it.

  cordis/lib/index.js:261  if (!name.startsWith("internal/")) this.emit("internal/dispatch", type, name, args, thisArg);
  cordis/lib/index.js:263  return (this._hooks[name] || []).filter((hook) => hook.global || !filter || filter.call(thisArg, hook.ctx)).map((hook) => hook.callback.bind(thisArg));

    -> `hook.global ||` short-circuits the scope predicate, and the same expression allocates a
       filtered array plus one bound closure per surviving listener, per dispatch.

What is measured vs inferred
----------------------------
  MEASURED   the nanosecond table above, on the shipped Cordis, with `selected_per_emit == N`
             showing the scope filter is bypassed; the linear fit slope and r2.
  MEASURED   the code paths quoted above, at those line numbers.
  INFERRED   the "O(sessions x follow streams)" characterisation of a whole process. It follows from
             the measured per-event cost being paid for every event dispatched in the process, but I
             did not instrument a production Host to count concurrent follow streams per event.
  NOT CLAIMED  I have not measured end-user latency caused by this term. It is one contributor among
             several on the same thread; this report isolates and quantifies the term itself.

Not claimed
-----------
  * This is not claimed to be the only or the dominant cost on the host's main thread.
  * No claim is made about browser-side rendering cost.
  * The absolute nanoseconds will differ on other hardware; the LINEARITY and the
    `selected_per_emit == N` behaviour are the portable findings.

Suggested fixes
---------------
  1. Key the subscription by session id instead of registering a per-follow global listener, so an
     event only reaches the streams that asked for that session. This removes the multiplicative
     term rather than shrinking it.
  2. If a global registration is unavoidable, hoist the id test into the dispatch predicate (the
     `filter` callback) rather than the listener body, so non-matching listeners are never selected
     and never bound.
  3. Consider resolving and caching the listener set per (name, scope) instead of rebuilding a
     filtered array plus bound closures on every dispatch.
  4. Expose a metric for dispatch time and listener-set size so this stays visible in production.

Reproduction
------------
  node ops/dsh/upstream-issue-follow-listener-fanout/follow-fanout-bench.mjs --selftest
  node ops/dsh/upstream-issue-follow-listener-fanout/follow-fanout-bench.mjs --n 0,1,2,4,8,16,32,64
  # last line: FOLLOW_FANOUT_BENCH ... result=LINEAR   (exit 0)
  # It imports the shipped Cordis Context from the installed bundle; no network, no DSH process,
  # no third-party dependency.

Related (not required to read): this is one term on a host that runs every session on a single
JavaScript main thread; I have reported that structure separately.