ProcessAsync: per-thread scratch cache, scaling gate, async rows, frame fix

[Astn]

Why

The best row did not fall from 30 M+ to about 10 M requests per second. The synchronous byte row still measures 31 M on this machine. The ~10 M figure came from the legacy string API's scheduled thread-pool mode, which the harness ran by default. The regression was in ProcessAsync, which was capped near 4 M RPC/s on every core count because every document took the AsyncScratch pool lock. The single-threaded micro-benchmarks cannot see a process-wide serialization point.

Two debate rounds (P1 to P5, then P6 and P7 on thread-local copies of shared data) settled the design; this PR implements every accepted resolution.

Library

• AsyncScratch per-thread slot. Each thread keeps one idle scratch in a [ThreadStatic] slot in front of the 64-slot locked pool, which now handles only misses and overflow. Rent clears the slot before exposing the lease. Return caches only a reusable scratch (reader released, buffers at most 64 KiB) and disposes the rest. This retains one scratch per thread that has run ProcessAsync plus 64 shared.
• Frame fix in Handler.AsyncScope.Dispose. The new cross-thread test found that cleanup of a Flow method under a pre/post hook gave the completing thread the starting thread's frame after a suspension. The two threads then shared one frame, so RpcContext, RpcRequestId and RpcSetException on either could read or clear the other's state during concurrent dispatch. The scope now restores the frame through the ambient value alone. FlowScope_CompletedOnAnotherThread_LeavesThatThreadItsOwnFrame reproduces it deterministically and fails on master.

Harness, CI, docs

• The harness adds TestServer_Console --async N W, --scale [seconds] [workers] [threshold] and --kestrel [seconds] [async]. The release gate measures inline rows at 1, 2 and N workers in three paired runs, takes the medians and fails with exit code 1 below the threshold. The legacy string benchmark moves to the t menu entry, and Enter runs the synchronous byte API.
• .github/request-path-sync.allowlist lists every lock, Interlocked, Volatile.Write, [ThreadStatic] field and writable static on the request-path files (core and both companion serializers), each with a reason. A checker job verifies the list. A non-required scaling job runs --scale 3 4 2.0 and writes its table to the step summary.
• The README adds an async section with measurements at 1 and 16 workers, per-shape allocations, the cost of a real suspension and Kestrel EnableAsyncMethods rows. The PR also updates the charts and explorer sets, CHANGELOG, Micro and AspNetCore READMEs.

Numbers

The Sync, Async, Legacy and Kestrel tables are from 2026-09-25 on the idle reference machine: three runs of --sync 3, the t entry and --kestrel 3, two of --kestrel 3 async, one 3 s run per --async row. The Performance table is one run per row in one session that day. The earlier busy-machine figures and the 2026-09-23 rows of those tables are gone from the README and the chart data, so the prose and the tables no longer mix days. The StreamJsonRpc and gRPC comparison, its in-process rows and the WebAssembly rows keep their 2026-09-23 results, and the conditions paragraph now says so per set.

Row	Before	After
ProcessAsync, inline methods, 16 workers	3.8 to 4.2 M	22.2 to 32.1 M
ProcessAsync, one real suspension, 16 workers	3.9 M	8.96 M
--scale 3 16 4.0, 16/1 ratio	1.3	7.1 to 7.3 (pass)
Process bytes, 16 threads, same session	31.7 M	31.7 M
Kestrel TCP, EnableAsyncMethods = true, inline	13.3 M (busy)	15.0 M to 15.4 M; the false row 14.3 M to 16.5 M
Kestrel TCP, EnableAsyncMethods = true, suspend once	1.13 M (busy)	1.25 M to 1.29 M
Process bytes, 16 threads, three runs	30.6 M to 35.8 M (2026-09-23)	31.7 M to 36.4 M
Legacy string API, best batch size	12.0 M (2026-09-23)	12.4 M to 13.3 M

The ValueTask<T> None row through ProcessAsync is above the synchronous entry point at 16 workers (32.1 M against 31.7 M) and the Task<T> None row just below it (30.0 M). The synchronous-methods row is at 24.6 M, about 78 % of it. The synchronous table, the default-mode Kestrel rows and the legacy table were re-measured the same day (three runs each) and replace the 2026-09-23 rows.

Performance section

The README (and so the docs site's front page) now opens with a Performance section. Its headline chart and table compare 1.2.3 against 2.0 on one machine in one session, with 3.08 M through the 1.2.3 string API, 13.3 M through the same API on 2.0, and 31.7 M and 32.1 M through the byte entry points. A paragraph explains why, followed by links to the full tables and the explorer. The 1.2.3 row comes from a new benchmarks/Baseline project that references the 1.2.3 package from NuGet and drives it with the same loop as the harness's legacy entry. Both sides of the comparison therefore use one harness shape on one day. The new linear bar chart in render.py (headline-1x-vs-2) is covered by render.py --check and two tests.

Tests

1163 pass on net8.0 and net10.0 in three consecutive full runs. New coverage includes AsyncScratchCacheTests (re-entrant, overlapping, 16 workers x 400 documents, cancellation after transfer, throwing reader release, oversized trimming) and the frame regression test above. render.py --check, test_render.py and the allowlist checker pass.

Follow-ups (P2, P6, P7 resolutions)

• Profile the async residual on the synchronous-methods row, which reaches 24.6 M through ProcessAsync against 31.7 M direct. That is about 78 %, just under the 80 % trigger. The ValueTask<T> None row is above the synchronous row and the Task<T> None row within 6 % of it.
• Test STJ TypeInfo<T>._last as a thread-static copy in an A/B. The merge bar is at least 5 % target gain beyond noise, with at most 2 % control regression.
• Add a miss/overflow counter on the AsyncScratch fallback before any second slot or striping. The named-parameter map is deferred.