[kacy]

The 2026-10-30 suite run read the HTTP server at 876k req/s at 32 connections and 1.45M at 256, against 1.22M and 1.83M in the published table. The Go and Rust servers reproduced their figures. A bisect over the 65 commits since the published run stopped at #1233.

In #1233, steal_pinned spun for up to 20us on every busy peer with a non-empty pinned fifo each time a worker ran out of work. A loaded server always has such peers, so its idle workers spent their time spinning. With steal_pinned turned off, the server read 1.22M and 1.98M again.

A worker now keeps a record of each peer's resume count and when it read it. It takes a task on a later pass if the peer is still running and the count has not moved for 20us. While it is watching a peer, it parks for 20us instead of backing off, so a stuck peer is still relieved quickly. The record is a local of the worker loop rather than a thread-local, because the TLS barrier check forbids a thread-local address in a frame that resumes tasks.

Measurements on a 9950X, server and benchmarks on cores 0-7,16-23:

• HTTP sweep (wrk -t16 from the other CCD), 2 runs of 6 s: 1.28M req/s at 32 connections, 1.99M at 256.
• A/B against main, medians of 7 interleaved rounds, ms:

benchmark	main	this change
chan_fanout	37.4	38.1
cpu_parallel_sync	658.1	658.1
green_fanout	629.7	635.3
task_pingpong	397.4	396.3
task_churn	1017.5	1011.7
metrics_contention/labels	90.6	86.2
metrics_contention/counter	615.3	617.8

lock_sweep/spawn and lock_sweep/breaker are bimodal on both builds, at about 36/48 ms and 87/113 ms. Over 15 interleaved rounds each, their medians match main.

Tests: runtime unit tests (the steal test now checks that the first look only records), TLS barrier check, green-thread tests, and the self-hosted regression corpus. The full gate suite also passed on the first version of this change.