docs: reset-aware handshake — spec note, component doc, Delmia/Ipsen notes, register row 119, CLAUDE.md (#36)

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

docs/plans/2026-06-17-waitfor-attribute-change-helper-spec.md

@@ -222,6 +222,15 @@ type/members don't collide with `ForbiddenIdentifiers` (`dynamic`, `Activator`)
   actor to evict the orphan waiter promptly (otherwise it self-evicts at its own timeout).
 - **Concurrency / re-entrancy.** Multiple waiters per instance are fine (keyed by `CorrelationId`).
   Consider a per-instance cap as a guard against a script leaking waiters in a loop.
+- **Handshake reset ordering (Gitea #36, design `2026-09-10-handshake-reset-echo-design.md`).**
+  The fast-path above is correct ONLY once the caller's reset has been observed. A script that
+  writes `CompleteFlag=false` and immediately calls the batch helper races the device echo: the
+  cache still holds the previous run's `true`, the wait fast-paths in 0 ms, and the script reads
+  stale results. An edge-triggered wait is NOT the fix (a subscription can swallow the reset when
+  the device flips inside one sampling interval); the reset must be echoed BEFORE the trigger is
+  written. Use the reset-aware `Attributes.WriteBatchAndWaitAsync(…, resetKey, resetValue,
+  resetTimeout)` overload, which returns a `HandshakeResult` (`ResetFailed` ⇒ nothing else was
+  written).
 
 ---