docs: write-completion correlation covers all four unary write kinds

gateway.md

@@ -431,9 +431,10 @@ Core commands:
 - `AuthenticateUser`
 - `ArchestrAUserToId`
 
-**Secured-write completion correlation.** MXAccess writes are fire-and-forget
+**Write completion correlation.** MXAccess writes are fire-and-forget
 at the toolkit level — the per-item outcome only exists in the later
-`OnWriteComplete` callback. For `WriteSecured` and `WriteSecured2` the worker
+`OnWriteComplete` callback. For the unary write kinds — `Write`, `Write2`,
+`WriteSecured`, `WriteSecured2` — the worker
 therefore holds the unary reply for a bounded window
 (`MxGateway:Worker:WriteCompletionWaitMilliseconds`, default 1.5 s, `0`
 disables) and, when the matching callback arrives, copies its status rows onto
@@ -444,8 +445,8 @@ empty `statuses` means unconfirmed (the callback missed the window), never
 failed. The `OnWriteComplete` event still flows on the event stream unchanged.
 Correlation is best-effort per `(server_handle, item_handle)` — the callback
 carries no transaction id, so concurrent writes to the same item within the
-window can swap rows. Plain `Write`/`Write2` and the bulk write commands stay
-fire-and-forget: waiting there would add a device round-trip of latency to
+window can swap rows. The bulk write commands stay
+fire-and-forget: waiting per entry would add a device round-trip of latency to
 high-rate supervisory write loops.
 
 Bulk variants (single gRPC round-trip carries the full list, the worker