Wording pass over the prose this branch adds

Shorter sentences and plainer verbs in the README, CHANGELOG, AspNetCore and Micro READMEs; no figure, identifier or link changed. Two factual slips fixed on the way: the Kestrel introduction no longer says every row ran with EnableAsyncMethods = false, and the Micro README's 0 B claim is scoped to the inline None rows.

Author: Astn

AustinHarris.JsonRpc.AspNetCore/README.md

@@ -75,16 +75,16 @@ app.MapJsonRpc("/legacy", new JsonRpcOptions { SessionId = "legacy-clients", Ser
 ## Services and lifetime
 
 `AddJsonRpcService<T>()` registers `T` as a singleton unless `T` is already registered. When the host starts,
-each registered service is resolved once from the root container and bound; that one instance then serves every
-HTTP request and every raw connection, concurrently. So `T` and its dependencies must be thread-safe, and `T`
-cannot take scoped dependencies such as an EF Core `DbContext`: with scope validation on, the host fails at
-startup; with it off, the dependency leaks. For per-request services, resolve them inside the method from
-`((HttpContext)Handler.RpcContext()).RequestServices` on HTTP; a raw connection's context is the
-`ConnectionContext`, which has no request scope. Do not inject request-scoped state into a service; read
-per-request data from the context instead.
+it resolves each registered service once from the root container and binds it. That one instance then serves
+every HTTP request and every raw connection concurrently. So `T` and its dependencies must be thread-safe.
+`T` cannot take scoped dependencies such as an EF Core `DbContext`. With scope validation on, the host fails
+at startup. With it off, the dependency leaks. On HTTP, resolve per-request services inside the method from
+`((HttpContext)Handler.RpcContext()).RequestServices`. A raw connection's context is the
+`ConnectionContext`, which has no request scope. Do not inject request-scoped state into a service.
+Read per-request data from the context instead.
 
 `AddJsonRpcServicesFromAssembly(assembly)` does the same for every non-abstract class in the assembly that
-declares a `[JsonRpcMethod]`. Private methods count, so the attribute is the whole access list, and an MVC
+declares a `[JsonRpcMethod]`. Private methods count, so the attribute is the whole access list. An MVC
 controller that carries it becomes a singleton too.
 
 The host binds every registered service to its effective session: the session given to `AddJsonRpcService`, else
@@ -123,13 +123,13 @@ invoked.
 
 - **HTTP:** the call is cancelled when the client disconnects (`HttpContext.RequestAborted`). Notifications are
   awaited and still answer `204`. The body reader stays leased until the invocation finishes.
-- **Raw connections:** documents are processed one at a time, in order, so 256 pipelined requests on one
-  connection are 256 sequential invocations, not 256 concurrent suspensions; concurrency comes from connections.
+- **Raw connections:** documents are processed one at a time, in order. On one connection, 256 pipelined requests
+  are 256 sequential invocations, not 256 concurrent suspensions. Concurrency comes from connections.
   Replies already finished are flushed before the connection waits on a slow method. When the connection closes,
-  the running method is waited for and its response discarded.
-- **Cost:** every document then goes through `ProcessAsync`. With methods that complete inline the TCP row measures
-  about 7 % below the synchronous mode (15.4 M against 16.5 M); a method that really suspends pays its own async state plus the
-  library's completion state (about 560 B) and a continuation per request. The main README's Kestrel table has
+  the handler waits for the running method to finish and discards its response.
+- **Cost:** every document then goes through `ProcessAsync`. With methods that complete inline, the TCP row measures
+  about 7 % below the synchronous mode (15.4 M against 16.5 M). A method that suspends pays for its own async state,
+  the library's completion state (about 560 B) and a continuation per request. The main README's Kestrel table has
   both rows, measured with `TestServer_Console --kestrel 3 async`.
 
 A method receives the token by declaring a `[JsonRpcCancellation] CancellationToken` parameter; see

CHANGELOG.md

@@ -23,12 +23,12 @@ behaviour: a breaking change to either means a new major version.
 - `Config.SetPreProcessHandler(sessionId, …)` and `Config.SetPostProcessHandler(sessionId, …)`, symmetric with the default-session setters. `Config.SetBeforeProcessHandler(sessionId, …)` remains as an obsolete alias.
 - `protected JsonRpcService(bool autoBind)`: a subclass constructed with `base(false)` binds itself nowhere, for services that a host or an explicit `BindService` call binds.
 - `SECURITY.md` (private vulnerability reporting) and this changelog.
-- `TestServer_Console --scale`: the release gate for the `ProcessAsync` path (the inline rows at 1, 2 and N workers, three paired runs, medians; fails when N/1 is below the threshold), `--kestrel [seconds] async` for the host with `EnableAsyncMethods = true`, and `--async` rows for `ProcessAsync` at 1 and 16 workers in the README. The 1.x string overloads' thread-pool benchmark is the `t` menu entry, no longer the default.
+- `TestServer_Console --scale` is the release gate for the `ProcessAsync` path. It measures the inline rows at 1, 2 and N workers in three paired runs, takes the medians and fails when N/1 is below the threshold. `--kestrel [seconds] async` runs the host with `EnableAsyncMethods = true`. The README adds `--async` rows for `ProcessAsync` at 1 and 16 workers. The 1.x string overloads' thread-pool benchmark is now the `t` menu entry and no longer the default.
 
 ### Changed
 
 - The core no longer depends on Json.NET.
-- `ProcessAsync` no longer serializes the process on one lock per document. The async scratch (input copy, reader, staged output) is cached one per thread in front of the shared pool, which is now the miss and overflow path only; on 16 threads the inline rows went from about 4 M to 22 M to 32 M RPC/s and a real suspension from 3.9 M to 9 M. Retention is one scratch per thread that has run `ProcessAsync` plus 64 shared, buffers at most 64 KiB each.
+- `ProcessAsync` no longer serializes the process on one lock per document. Each thread now caches one async scratch (input copy, reader, staged output) in front of the shared pool, which handles only misses and overflow. On 16 threads, the inline rows went from about 4 M to 22 M to 32 M RPC/s, and the row with a real suspension went from 3.9 M to 9 M. The library retains one scratch per thread that has run `ProcessAsync` plus 64 shared, with buffers at most 64 KiB each.
 - The request path looks sessions up without creating them. A request for a session id that was never registered answers `-32601` for every call and leaves the registry untouched; sessions are created by binding and by the per-session `Config` setters. Registration adds the session before publishing the registry version, so a thread that misses its snapshot consults the master registry and cannot answer `-32601` for a session that exists.
 - The AspNetCore host binds every registered service, `JsonRpcService` subclasses included, to its effective session (the registration's session, then `JsonRpcOptions.SessionId`, then the default). It no longer skips a subclass on the default session.
 - The core package's description says "no JSON library dependency" instead of "no dependencies". The session registry uses the framework's `ConcurrentDictionary`; the `NonBlocking` package reference is gone, so the core has no dependencies on `net8.0` and `net10.0` (measured with `SessionRegistryBenchmarks`: unknown-id lookups and register/destroy cycles got faster, stable lookups and dispatch are unchanged).
@@ -49,7 +49,7 @@ behaviour: a breaking change to either means a new major version.
 
 - A trailing notification in a batch no longer leaves a dangling comma.
 - `async void` methods are rejected at registration.
-- A method registered with `RpcContextFlow.Flow` that suspends under a pre- or post-processing hook and completes on another thread no longer hands that thread the frame of the thread that started it. Afterwards the two threads shared one frame, so `RpcContext`, `RpcRequestId` and `RpcSetException` on either could read or clear the other's while both dispatched. Found by the new cross-thread `ProcessAsync` test; the frame is now restored through the ambient value alone.
+- A method registered with `RpcContextFlow.Flow` that suspends under a pre- or post-processing hook and completes on another thread no longer gives the completing thread the starting thread's frame. Previously, 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 new cross-thread `ProcessAsync` test found this bug. The frame is now restored through the ambient value alone.
 
 ### Security