docs(worker): record live item-handle-reuse probe for ack writer

Add the Skip-gated ItemHandleReuseProbeTests probe and its windev result
(2026-10-20): within one MXAccess registration, item handles increase
monotonically and are never reused across remove/re-add, so the ack
writer's Unconfirmed drop-and-re-add mitigation holds and no per-handle
generation counter is needed. Numbering restarts only on a new
registration, which teardown already isolates. Document the guarantee at
the Dirty re-add and in AlarmProbeFindings.md.

Fixes #166

Claude-Session: https://claude.ai/code/session_016J6isfcgqy4SB2RK3ZvFvT

docs/MxAccessWorkerInstanceDesign.md

@@ -356,7 +356,10 @@ stay acceptance-only regardless of which completion (if any) was attributed.
 `MxAccessWriteCompletionCache` and reuses one advised `AckMsg` item per alarm
 (least-recently-used, capped at 256). After an ack ends unconfirmed it marks the
 item dirty, and the next ack to that alarm removes and re-adds the item so the
-write waits on a fresh item handle the stale completion cannot match. Every
+write waits on a fresh item handle the stale completion cannot match. This
+relies on MXAccess never reusing an item handle number within one
+registration, which a live probe confirmed (see "Item handle reuse" in
+[Alarm Probe Findings](./AlarmProbeFindings.md)). Every
 drop of an item (dirty re-add, eviction, or a failed `AddItem`/`Advise`/`Write`)
 also removes that handle's completion entry, and tearing down the registration
 removes every entry for its server handle, so the cache does not grow by one