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

docs/DesignDecisions.md

@@ -534,7 +534,7 @@ against the live MXAccess attribute set.
 - [Alarm Client Discovery — Subtag provider](./AlarmClientDiscovery.md)
 - [gRPC Contract — provider_status and degraded fields](./Grpc.md)
 
-## Secured-Write Completion Correlation
+## Write Completion Correlation
 
 MXAccess writes are fire-and-forget: the toolkit call returns before the
 Galaxy commit, and the per-item outcome only exists in the later
@@ -542,7 +542,8 @@ Galaxy commit, and the per-item outcome only exists in the later
 proved worker-side command acceptance only, forcing consumers (OtOpcUa's
 GalaxyDriver) to report every write as provisionally good.
 
-For `WriteSecured`/`WriteSecured2` the worker now holds the unary reply for a
+For the unary write kinds (`Write`/`Write2`/`WriteSecured`/`WriteSecured2`)
+the worker now holds the unary reply for a
 bounded window (`MxGateway:Worker:WriteCompletionWaitMilliseconds`, default
 1.5 s, `0` disables; conveyed to the worker via
 `MXGATEWAY_WORKER_WRITE_COMPLETION_WAIT_MS`) and copies the matching
@@ -565,9 +566,13 @@ callback's status rows onto `MxCommandReply.statuses`. Key choices, argued in
   acceptance; the MXAccess outcome (success or failure) rides only in
   `statuses[0]`; the `OnWriteComplete` event still streams unchanged (nothing
   swallowed, nothing synthesized).
-- **Scope: secured writes only.** Plain `Write`/`Write2` and bulk writes stay
-  fire-and-forget — the wait would add a device round-trip per write to
-  high-rate supervisory loops.
+- **Scope: all four unary write kinds; bulk writes stay fire-and-forget.**
+  The first cut correlated `WriteSecured`/`WriteSecured2` only, but OtOpcUa's
+  dominant FreeAccess write path goes out as plain `Write` (2026-08-09 live
+  verification, 06/S-1) — a refused plain write was invisible on the reply.
+  Plain `Write`/`Write2` now correlate identically. Bulk writes keep
+  fire-and-forget replies: waiting per entry would add a device round-trip per
+  item to high-rate supervisory loops.
 - **Best-effort correlation.** The callback carries only
   `(hItem, statuses)` — no transaction id — so concurrent writes to the same
   item within the window can swap rows; benign for the serialized single-write