控制面一元 RPC 在主线程饱和时被饿死：同一份约 0.5 s CPU 的 session/list，实测被拉长到 34 s – ≥45 s（45 s 是客户端 socket 超时的右截尾；放大已在隔离副本上复现 3.75×、按自身 CPU 归一 5.62×，生产 stall 当刻的配对样本已在 user-d 户补齐（17:48–18:07））

① 这条 RPC 是纯主线程的约 0.5 s CPU 活，成本随会话数线性

本页采纳的唯一权威组 A0（16:10:06–16:10:09，经网关 5006、rpcId=fixed、6 发，同刻无 stall）：wall 中位 517.4 ms（逐发 638.5 / 517.4 / 521.8 / 522.4 / 505.9 / 504.6），同发主线程 utime+stime 差 中位 405.1 ms（逐发 533.6 / 405.1 / 395.3 / 405.1 / 424.9 / 375.5），即 74.4–84.0% of one core；rows=660（6 发同值）、响应 1,578,662 字节（6 发同值，rpcId=fixed）、sha256=923a9bf90594c61e… ⇒ 6/6 逐字节一致。字节数必须与所用 rpcId 绑在一起写：它随 rpcId 的长度变，也随当刻会话集漂（同机另一轮 rpcId=stall-instrument-fixed（22 字符）是 1,578,679 B；历史组 rpcId=f"p{i}"（2 字符）是 1,578,663 B）—— 拿旧脚本的 3 发做例子：rpcId=p0/p1/p2 时三发只有长度一致、sha256 互异（23a6ff3a58fee714 / 8d3198fc84bd2f16 / bbcfe709b698507d），差异只在 byte 35 起的回显 rpcId。一份独立实现（sudo -n python3 + http.client，16:14:5x，3 发）给到同字节同 sha：wall 559.0/546.7/467.3、main_cpu 450/480/370、rows=660、bytes=1578662。两个口径分开写：wall/rows = 0.784 ms/会话（0.765–0.968），cpu/rows = 0.614 ms/会话（0.569–0.809）。成本几乎全在主线程、且几乎全在首字节之前：TTFB 中位 510.8 ms（489.3–630.6）⇒ TTFB/wall = 96.97–99.56%，1,578,662 B 的传输只占 2.3–15.3 ms。历史组 H1–H4（含 EVID 14:1x 六发 wall 527–621 ms、CPU 400–520 ms）同量级，只用于对比通路。没有第二个进程、第二条线程在替它干活：代码路径逐会话顺序 await（dsh-session-persistence-jsonl/lib/index.js:2858 listArtifacts() → :2864/:2866 两层 for → :2868 → :2872，每层都是 await），list() 之后还要对每个会话再 await stat() 一次（:2459/:2462）；同组复核给出该发全线程 CPU 533.6–1255.0 ms（其中 libuv-worker 只 108.7–138.3 ms、threads=11 恒定）⇒ CPU 主要在 main，但不是只有 main。

② 饱和时它不是「慢」，是「排队」：隔离副本上 8 路并发把同一发 RPC 拉长 3.75×（按自身 CPU 归一 5.62×），而同窗轻请求中位仍 3.4 ms

看门狗日志给出同一台机器上两种结局（user-a 户，截至 15:09 截断）：成功样本 n=1429，min=5 / p50=493 / p90=756 / max=28715 ms；RED 37 条，分四类：读超时 timed out 20 条（45010–45045 ms）、网关不可达 10 条（Connection refused，全落在重启窗口）、「算完了但超预算」6 条（hard=False，不重启：21:24:05 rows=531/42396ms、23:36:58 rows=601/36006ms、23:37:11 rows=601/37379ms、07:36:46 rows=633/44389ms、07:38:31 rows=633/34259ms、07:41:27 rows=633/37392ms）、reset 1 条（Connection reset by peer，9/14 15:54:29）。四类相加 20+10+6+1 = 37。45 s 那 20 条是右截尾：客户端 socket 预算 = 30 s + slack 15 s，到点即断，真实停顿 ≥45 s；那 45 s 里有多少是排队、多少是算不完，生产当刻仍然没有样本。放大律已在隔离副本上受控实测（ops/dsh/upstream-issue-main-thread-control-plane/queue-amplification-sweep.mjs，目标 127.0.0.1:4099 的隔离 DSH 实例 pid 41122、665 行副本，生产端口一个字节都没发）：同刻发起 K 发 session/list，窗口两端掐目标主线程 utime+stime（标定 clk_tck=96.928），并每 400 ms 并行插一串轻请求 canary（GET /favicon.ico + GET /api/ping，都走同一条主线程）：
K=1: wall_p50 509.1 ms（相对 K=1 基线 568.0 = 0.896×）、cpu_per_call 448.8 ms、cpu_pct_of_wall 88.0%、canary_p50 2.8 ms
K=2: 668.9 ms（1.178×）、374.0 ms、100.5%、2.6 ms
K=4: 1093.8 ms（1.926×）、341.8 ms、101.8%、2.8 ms
K=8: 2131.6 ms（3.752×）、330.8 ms、101.3%、3.0 ms —— 判词行 QUEUE_AMPLIFICATION k=8 wall_p50_ms=2131.6 cpu_total_ms=2646.3 cpu_per_call_ms=330.8 canary_p50_ms=3.0 amplification_vs_k1=3.752（完整原文：ops/dsh/upstream-issue-main-thread-control-plane/evidence-queue-amplification.txt；第二轮整跑（原始输出 evidence-queue-amplification-run2.txt）复现同一量级：K=8 wall_p50 2152.7 ms（amp 3.548）、K=4 1172.0、K=2 699.3、K=1 561.0（基线 606.7 ms、684 行））。读法：并发到 8 时单发 wall 是 K=1 的 3.75×，而单发自己烧的 CPU 反而降到 0.668×（495.2→330.8 ms）⇒ 墙钟抬升不是这条 RPC 多烧了 CPU，而是它要跟同进程另外 7 发抢同一条主线程；窗口内 cpu_pct_of_wall=101.3%（>100 是 10 ms tick 粒度 + 两端不同钟，未钳位）说明主线程已饱和。按自身 CPU 归一后放大 amplification_cpu_normalized=5.618×（脚本原字段；其 wall/cpu 比从 K=1 的 1.134 升到 K=8 的 6.445）。同刻 canary 对照就是生产签名的复制：K=8 最坏一发 RPC 2970.3 ms，而同窗 canary 中位只有 3.4 ms ⇒ 873×（QUEUE_AMPLIFICATION_CANARY_CONTRAST … ratio_wall_over_canary_p50=873.618）——「轻的还快、重的慢到秒级」，与「13:21:32 网关探针 OK 而 list 读超时」同形。尾巴如实报：canary_max 随 K 恶化 13.2 → 256.5 → 425.8 → 1233.7 ms，≥200 ms 占比 0/24 → 4/24 → 6/34 → 8/48，K=8 的尖峰 4/4 窗都落在窗内 ~1.3–1.7 s 处（形状提示读完 fs 后有一段几百 ms 的主线程同步块会把轻请求一起堵住；那是观察到的相位，不是已验证的成因）。fs 调用数也从「结构推算」升级为实测（sudo -n strace -f -tt -e trace=openat,read,close -p 41122，窗内含一发 list，空闲头/尾窗的文件 fs 调用均为 0，故全部记在该 RPC 账上）：fs_calls_in_call=3333（openat=1334 + pool 线程 read=665 + pool 线程 close=1334）/ rows=665 ⇒ 每会话 5.012 次（openat 2.006 + read 1.000 + close 2.006），实测 3333/665 = 5.012（原始输出 evidence-queue-amplification.txt 第 65 行；第一轮探索性 strace 的另一组 3328/664 未保留原始行，本页不引用） —— 此前推断的「约 3,300 次 / 每会话约 5 次」被证实。但「让出执行权次数」仍没有单独计数（没有 event-loop 层 hook），所以「45 s ÷ 次数」这类槽位时延仍然算不出来，本页不再给 ms/槽：旧稿按 3,300 次算出的 13.6 ms/槽（按 syscr ≈5,300 则是 8.5 ms/槽）已删，因为分母本身就不是「让出次数」。能替代它的是可测的饱和口径（cpu_pct_of_wall 101.3%）与可测的放大倍率（3.75× / 5.62×）。并发摊薄的是事件循环唤醒、不是文件读：8 发串行 list 使 /proc/41122/io 的 syscr +44273（5534/发，单发 +5320），而 K=8 并发窗只有 ~10775（≈1347/发）—— 主线程事件循环 read 是 4661 次/发（7.009/会话），一次唤醒服务多个回调所以越并发越少；而 pool 线程上的文件读按 strace 仍是每发 665 次、线性。

③ 越过 45 s 就从「慢」变「坏」：自愈重启 → 在途调用腰斩 → TOOL_OUTCOME_UNKNOWN

13:21:51 RED … 45045ms timed out → 13:22:01 SESSION_LIST_HEALTH_HEALED user=user-a（重启）→ 13:22:04 RED … 网关不可达（5006）：Connection refused；13:38:39 那条读超时 → 13:38:49 HEALED 是第二幕。窗口内的启动次数本页本轮已复量，来源是本机 /home/user-a/.dsh/logs/web.log（需 sudo，见「实测锚点」第 6 段）：全文件 15 行 start user=user-a，其中 13 行落在窗口内（≥ 2026-09-14 01:01:23）；日志里 SESSION_LIST_HEALTH_HEALED user=user-a 共 11 次。后果是冷加载 resume 合成 4 会话 / 20 条 TOOL_OUTCOME_UNKNOWN（workflow 15 · bash 3 · job_output 2；EVID #33，本页未复测生产会话文件）。这条链的下半段已在隔离副本上逐步实测（ops/dsh/graceful-stop-verify/）：SIGTERM 后在飞工具调用确实只有 call 没有 result（seq16 tool/call 之后耐久日志里 0 条 tool/result、也没有 step/end / turn/end），且**必须在下次冷加载 resume 时才补合成** —— 见「影响面」第 5–6 行的 A/B 数字。这一条只算影响面：缺陷是「控制面 RPC 没有第二条执行体」加「慢与坏同形」；即使永不重启，34 s – ≥45 s 的列表也已不可用。

Title: Control-plane unary RPCs are starved on the shared JS main thread: the same
       0.5 s-CPU session/list call measures 34 s to >=45 s under load; the queueing
       amplification is REPRODUCED on an isolated replica (3.75x at 8-way concurrency),
       while the production stall itself still has no in-process sample
       (the 45 s bound is a right-censored client socket timeout: 30 s budget + 15 s slack)
Summary
-------
A DSH host is one Node process with a single JS main thread shared by every session,
every subagent and every RPC. `session/list` is a unary, control-plane RPC that walks
the entire session store sequentially, one `await` per session. Measured on an idle
process (AUTHORITY GROUP A0: 2026-09-15 16:10:06-16:10:09, over the gateway on 5006,
`rpcId=fixed`, 6 replays against the same pid): 660 rows, 1,578,662 bytes, 504.6-638.5 ms of
wall time (median 517.4) against 375.5-533.6 ms of main-thread CPU (median 405.1, i.e.
74.4-84.0 % of one core) - that is 0.784 ms per session by wall time and 0.614 ms by CPU
time; keep those two units apart. First byte is 96.97-99.56 % of wall (TTFB median 510.8 ms),
so of the 1,578,662 bytes at most 2.3-15.3 ms is transport. Measured on the same process
while other sessions are running: 34 s to >=45 s. The 45 s bound is a right-censored client
socket timeout (30 s budget + 15 s slack), so the real stall is >=45 s.

That queueing mechanism is now REPRODUCED, under controlled conditions, on an isolated
replica (127.0.0.1:4099, 665 rows, production ports untouched): 8 concurrent `session/list`
calls on the same process give wall_p50 2131.6 ms = 3.75x the K=1 replay (5.62x once
normalised by the call's own CPU, which DROPS to 0.668x), with the main thread at
cpu_pct_of_wall 101.3 % (saturated), while a light canary request in the same window still
has a 3.4 ms median - an 873x contrast (worst call 2970.3 ms vs that 3.4 ms median), the same shape as "gateway probe OK while list times
out" in production. What we still do NOT have is any in-process sample for a PRODUCTION
stall, and production's 54-89x (34,259-45,000 ms over the 504.6-638.5 ms A0 wall) is much
larger than the replica's 3.75x: the replica proves the mechanism, not the 45 s magnitude.

The scan does not get slower - it gets re-queued. `strace` on an isolated 665-row replica
counts the fs work exactly: 3333 fs calls for one `session/list` (openat 1334 + thread-pool
read 665 + thread-pool close 1334) = 5.012 calls per session (2.006 + 1.000 + 2.006); one strace run gives 3333 fs calls / 665 rows = 5.012 per session (raw output: evidence-queue-amplification.txt line 65), and the idle windows before and
after the call show 0 file fs calls, so all of them belong to that RPC. The main thread's
event-loop reads are a separate account (4661 per call = 7.009 per session) and they ARE
amortised by concurrency (5534 per call when serial vs ~1347 per call at K=8), while the
thread-pool file reads stay exactly linear (665 per call). We still do NOT count event-loop
yields, so we no longer quote any "ms per yield": 45,000 ms / 3,300 ~= 13.6 ms per slot used
the wrong denominator and has been removed.

The observable consequence is worse than the latency: on this wire "slow" and "broken"
look identical. The same event yields either a correct response at 34-44 s or a
client-side timeout at 45 s (45010-45045 ms), and only a local script can tell them
apart. We do not claim the front end filters subagent sessions.

Shutdown A/B/C on the same isolated replica (measured, headless carrier): with SIGTERM the
process exits BY ITSELF in 128-134 ms, so a 6 s grace is never used (hard_kill_at_ms=0), and
the durable log ends at the `tool/call` with 0 `tool/result` rows - no step/end, no turn/end.
The synthetic TOOL_OUTCOME_UNKNOWN appears only on the next cold resume. The arm that DOES
write a cancellation result is `session/cancel` (error_code ABORTED, then step/end, turn/end).
In other words: widening the grace from 0.3 s to 6 s does not fix the lost tool result.

Why this matters
----------------
A control-plane RPC that lists metadata should not compete with the work it describes.
The 45 s timeout was not cosmetic: our watchdog treated it as a hard failure and, after
two in a row, restarted the service. Restarting killed in-flight tool calls - the wrapper
sent SIGKILL 0.3 s after SIGTERM while the process itself grants 5 s - and they came back
on the next cold resume as synthetic TOOL_OUTCOME_UNKNOWN results: 13 starts in two days,
11 from this path, 20 results lost across 4 sessions. We have since changed both locally
(a read timeout is no longer a restart trigger, and the grace is 6 s); the starvation is
unchanged, and fixing only the watchdog would hide it - on an idle process the call is
534-616 ms, so under load it is still 56-84x its wall time (65-113x its measured CPU
cost) whenever the process is busy.

Environment
-----------
  DSH 0.1.5-rc.1 (shipped lib/); one systemd unit, one Node process and one gateway per
  user; the measured user returns 660 rows (660 session directories on disk, origin
  histogram {subagent: 648, none: 12}, 246 MB), 648 of them subagent sessions; web on
  127.0.0.1:4006 behind a gateway on 0.0.0.0:5006.

Evidence (measured)
-------------------
  AUTHORITY GROUP A0 (2026-09-15 16:10:06-16:10:09, over the gateway on 5006,
  rpcId=fixed, 6 read-only session/list replays against the same pid; main-thread CPU from
  /proc/PID/task/PID/stat utime+stime; reproduce with:
    node ops/dsh/stall-instrument/stall-instrument.mjs --authority 6 --rpc-id fixed ):
    call0: wall=638.5ms ttfb=630.6ms cpu=533.6ms (83.6% of one core) rows=660 bytes=1578662
    call1: wall=517.4ms ttfb=510.8ms cpu=405.1ms (78.3% of one core) rows=660 bytes=1578662
    call2: wall=521.8ms ttfb=513.2ms cpu=395.3ms (75.8% of one core) rows=660 bytes=1578662
    call3: wall=522.4ms ttfb=520.1ms cpu=405.1ms (77.5% of one core) rows=660 bytes=1578662
    call4: wall=505.9ms ttfb=502.2ms cpu=424.9ms (84.0% of one core) rows=660 bytes=1578662
    call5: wall=504.6ms ttfb=489.3ms cpu=375.5ms (74.4% of one core) rows=660 bytes=1578662
  (median wall 517.4 / TTFB 510.8 / CPU 405.1 ms; sha256 923a9bf90594c61e on all six - pinning
  rpcId=fixed is what makes them byte-identical. An independent python3/http.client
  implementation reproduced the same bytes and sha at 16:14:5x. Historical groups H1-H4 -
  e.g. 15:10:08-15:10:13: wall 616/572/534 ms, cpu 530/460/400 ms, rows=660, bytes=1578663
  under rpcId=f"p{i}" - are kept for path comparison only and must NOT replace A0.)

  Local watchdog log for the same user, truncated at a fixed timestamp (it grows every
  minute; cutoff here: < "2026-09-15 15:09"): n=1429 successes, min=5ms p50=493ms p90=756ms,
  max=28715ms, and 37 RED rows. Per-call CPU was NOT sampled during any stalled window;
  the A0 idle-process numbers above are the only main-thread CPU measurements we have for
  production (the replica K-sweep below is a copy, not production).

  RED rows split into four kinds (20 + 10 + 6 + 1 = 37), not two:
    read timeouts at the client, 20 rows, 45010-45045 ms (hard failure, restart after two
    in a row; right-censored by the 30 s budget + 15 s slack socket timeout):
      45044, 45023, 45010, 45045, 45045, 45045, 45045, 45024, 45045, 45042,
      45045, 45045, 45045, 45045, 45045, 45044, 45029, 45045, 45045, 45026 ms
    gateway unreachable, 10 rows: Connection refused, every one inside a restart window
    (e.g. 13:22:04, three seconds after the 13:22:01 restart).
    correct but over budget (not a hard failure, no restart), 6 rows:
      42396 ms  rows=531
      36006 ms  rows=601
      37379 ms  rows=601
      44389 ms  rows=633
      34259 ms  rows=633
      37392 ms  rows=633

  Same machine, same minute, other users (each with its own process and session store)
  are healthy: 620-732 ms for 776 rows, 1736-2277 ms for 3141 rows, 332-404 ms for 335
  rows, 2-9 ms for 0-2 rows. That 3141-row user measured over the whole window (n=1463
  successes truncated at 15:09) is min 1633 / p50 2023 / p90 2352 / max 19515 ms - the same
  disk-reading work never approaches 45 s. A gateway probe reaching the same web process over the same
  gateway (different path, 6 s timeout) returned OK at 13:20:32, 13:21:32 and 13:22:32 -
  the middle one inside the 45 s timeout window. The process is not hung.

What is measured vs inferred
----------------------------
  * Measured: per-call wall time, per-call main-thread CPU, TTFB, response size, row count,
    the distribution above, the two failure shapes, the fs-call count per call (strace on a
    replica), and the queueing amplification on that replica. Every PRODUCTION CPU number
    here comes from an IDLE process (A0, 16:10:06-16:10:09); no per-call CPU sample exists
    for any stalled window.
  * Reproduced (controlled, isolated replica): 8 concurrent session/list calls re-queue behind
    each other - wall 3.75x, cpu-normalised 5.62x, main thread saturated at cpu_pct_of_wall
    101.3 %, while a light canary in the same window keeps a 3.4 ms median (873x: worst call 2970.3 ms vs 3.4 ms median).
    What is still missing is NOT the mechanism but the production sample: we have no
    concurrent main-thread-utilisation sample for a PRODUCTION stall, and we deliberately did
    not load-test a production process. 45 s is a right-censored client socket timeout
    (30 s budget + 15 s slack), so the real stall is >=45 s.
  * Measured (previously inferred): the fs-call magnitude. strace on a 665-row replica gives
    3333 fs calls per session/list = 5.012 per session (openat 1334 + pool-thread read 665 +
    pool-thread close 1334; raw output in evidence-queue-amplification.txt line 65), with 0 background fs
    calls in the idle windows. Event-loop yields are still NOT counted - therefore no
    "ms per yield" figure is quoted anywhere in this issue.
  * Not excluded: libuv thread-pool QUEUE DEPTH (the pool's own CPU is small - 108.7-138.3 ms
    per call - and its file reads are linear at 665 per call, but queue depth / wait latency
    was never measured and nothing was sampled during a real stall), response-side backpressure
    INSIDE A STALL WINDOW (on an idle process TTFB is 96.97-99.56 % of wall and transport is
    only 2.3-15.3 ms, so it is bounded there), and the per-event cost of the #11
    session/follow fan-out, which shares this thread with all 660 sessions.
  * Field instrumentation for the next stall is now RUNNING, read-only and resident:
    a 2 s canary latency series, 1 Hz per-thread main-thread CPU sampling, and a 60 s
    session/list recording wall/TTFB/rows/bytes. It writes a STALL_CAUGHT record when
    list > 5 s or canary > 2 s, with 30 s of context on either side. 16.3 min window so far:
    0 triggers (all idle baseline). We are waiting for the next real stall instead of
    manufacturing one on a production process.
Code references (0.1.5-rc.1, shipped lib/)
-----------------------------------------
  1. `dsh-session-persistence-jsonl/lib/index.js:2858` - `async listArtifacts(signal) {`,
     `:2864` `for (const project of await this.listProjectDirs(signal)) {`, `:2866` `for
     (const dir of await this.listSessionDirs(project, signal)) {`, `:2868` `const selected
     = await this.resolveGenerationInDirectory(dir, signal);`, `:2872` `header = await
     this.readGenerationHeader(selected, void 0, signal);` - every level is a sequential
     await; no batching, no page size.
  2. `dsh-session-persistence-jsonl/lib/index.js:2459` - `for (const artifact of await
     this.listArtifacts(signal)) {` followed by `:2462` `const identity = await
     stat(artifact.path, { bigint: true });` - a third sequential await per session,
     outside listArtifacts.
  3. `dsh-session-persistence-jsonl/lib/index.js:3278` - `this.rootEncodingCheck ??=
     this.checkRootEncoding();` - memoised, but checkRootEncoding() (`:3281-3285`) walks
     the same tree once, so a cold process scans everything twice.
  4. `dsh-session-persistence-jsonl/lib/index.js:3127-3146` - the header read is a JS
     loop: `await open(...)`, 8 KB `await handle.read(...)` chunks, a `Buffer.concat`
     per chunk, `scanZstdFrames(content, 1)` and `await decompressZstdFrame(...)`.
     Cost grows with file size, not only with session count.
  5. `dsh-api-session-controller/lib/typert.host.js:896-900` - the RPC descriptor:
     `id: '@deepseek-ai/dsh-api-session-controller#session/list'`, `service:
     'sessionController'`, `method: 'list'`, `invocation: { kind: 'direct' }`. All 84
     RPC descriptors in the shipped `typert.host.js` files use `kind: 'direct'`; there
     is no worker/queue/priority alternative to opt into.
  6. `dsh-api-gateway/lib/index.js:811` - `let receiver = { kind: "direct" };` and
     `:837` `if (descriptor.invocation.kind === "direct") return this.ctx;` - "direct"
     means the handler runs on the same ctx, i.e. the same process and the same main
     thread.

Ruled out (all measured)
------------------------
  * Not the scan volume: at 0.784 ms per session by wall time (0.614 ms by CPU time,
    A0) a 45 s budget needs 46,488-79,086 sessions, and this user has 660 rows. Another
    user with 3,141 rows on the same box takes 1.7-2.3 s in its own process (n=1463
    successes, max 19,515 ms) - same slope, two orders of magnitude off.
  * Not disk or filesystem: main-thread CPU is 74.4-84.0 % of wall time on the idle
    process (A0; 73.6-83.7 % across the EVID replays), so time is spent in JS. The remaining
    16-26 % is not decomposed into I/O wait versus scheduling.
  * Not a hung process, machine or gateway: other users' processes are healthy in the
    same round; the gateway probe to the same web process is OK inside the timeout
    window; the response content is identical (A0: rows=660 and bytes=1,578,662 on all six,
    sha256 923a9bf90594c61e identical once the rpcId is pinned - otherwise only the echoed
    rpcId at byte 35 differs).
  * NOT excluded (do not quote these as ruled out): libuv thread-pool QUEUE DEPTH (4 workers;
    strace measures 3333 fs calls per session/list = 5.012 per session with linear 665-per-call
    thread-pool reads, and the pool burns only 108.7-138.3 ms per call, but queue depth and
    wait latency were never measured and nothing was sampled during a real stall);
    response-side backpressure INSIDE A STALL WINDOW, because TTFB there was never separated
    from total time (on the idle process it is 96.97-99.56 % of wall, transport 2.3-15.3 ms);
    and the per-event cost of the #11 session/follow fan-out, which shares this thread with all
    660 sessions.

Not claimed
-----------
  * We do not claim the shared main thread is the only cost in DSH, only that it makes
    this control-plane RPC unusable under load.
  * We do not claim the front end does or does not filter subagent sessions; we only
    observed that session/list returns them and that the scan pays for them.
  * We do not claim any particular decomposition of the amplification (JS queue vs thread
    pool), and we do not claim any yield count: 3333 is a measured syscall count for one call,
    the event-loop read count (4661) is measured too, but neither is an event-loop YIELD
    counter - which is why no ms-per-yield figure appears in this issue.

Suggested fixes
---------------
  1. Give control-plane RPCs their own execution body, or at least a preemptible
     channel. STRUCTURAL JUDGEMENT plus a reproduced mechanism: that all 84 descriptors are
     `kind: 'direct'` is measured, and the queueing amplification is measured on an isolated
     replica (3.75x wall / 5.62x cpu-normalised at 8-way concurrency, main thread saturated);
     the magnitude inside a PRODUCTION stall is still not evidenced.
     `kind: 'direct'` puts session/list on the same main thread as inference
     work; moving the directory walk and header decoding to a worker or thread pool, or
     yielding between scan slices with a way for an interactive request to jump the
     queue, would remove the amplification.
  2. Add an index and pagination for the session store. A sidecar index keyed by
     directory mtime and file size turns the call into one read plus a cursor, and the
     648/660 subagent sessions can be filtered server-side instead of scanned and then
     discarded.
  3. Export the three numbers that separate "slow" from "broken" per RPC, as
     percentiles: queue wait before first scheduling, execution time, yield count. With
     those, a 45 s timeout and a 44 s correct answer become visibly different events.

Reproduction
------------
  Read-only: replay one session/list over the gateway and sample the main thread's
  utime+stime from /proc/PID/task/PID/stat before and after the call. Expect
  main_thread_cpu / wall in the 0.744-0.840 range (AUTHORITY GROUP A0: 16:10:06-16:10:09,
  6 replays, rpcId=fixed, wall median 517.4 ms, TTFB median 510.8 ms), with identical rows and
  identical byte LENGTH across calls (pin the rpcId for equal bytes) - and read the TTFB too,
  because first byte is 96.97-99.56 % of wall - but read it together with
  (a) a concurrent canary request's latency and (b) the
  TARGET process's main-thread utilisation, never as a standalone verdict.
  To reproduce the queueing amplification and the shutdown result without touching production:
  run ops/dsh/upstream-issue-main-thread-control-plane/queue-amplification-sweep.mjs against an
  isolated copy (K sweep: wall_p50 509.1 / 668.9 / 1093.8 / 2131.6 ms for K=1/2/4/8), and
  ops/dsh/graceful-stop-verify/verify-graceful-stop.sh --arms A,B,C for the shutdown A/B/C.
  Do NOT run either against a production process.
  it concurrently against a production process: that manufactures the timeout behind the
  restarts reported above.

Related (not required to read): our earlier notes on the same RPC (a zero-byte stall
and a fail-closed empty list) and on the single-main-thread capacity model. This issue
is self-contained.