docs(wake): explain why the detector's sleep child closes fd 9 (#993 review)

A bare `9>&-` on the sleep line reads as removable redirection noise. It is
not: it is what stops an orphaned `sleep` from holding the per-host
single-instance flock (fd 9, opened at `exec 9>"$lock"`) after the detector
parent dies, which would leave a lock no replacement instance can ever
acquire. The comment also states the half that makes the fix safe — `9>&-`
closes ONLY the child's copy, so the parent detector's lock is untouched.

Comment-only. Verified: stripping comment lines from this file yields output
byte-identical to the same operation on the reviewed head 60f8caf4d8 (397
non-comment lines both sides), so no executable line changed. `bash -n` and
`git diff --check` pass. The file is now 576 lines, not 572, and the sole
sleep site moves from line 532 to 536 — rev-974's line derivations need
recomputing at the new sha.

Requested by rev-974 in the CHANGES-REQUIRED verdict on #993 (comment 19818),
which bound to head 60f8caf4d8. That verdict is void at this new sha by the
standing verdict-at-head rule; re-verdict required before merge.

packages/mosaic/framework/tools/wake/detector.sh

@@ -529,6 +529,10 @@ cmd_run() {
         echo "detector.sh: WARN — off-host liveness beacon emit failed (see beacon.sh); the off-host absence check remains the authoritative dead-man." >&2
     fi
     [ "$once" -eq 1 ] && break
+    # Close the detector lock fd in the sleep child; otherwise an orphaned sleep
+    # keeps the single-instance flock (fd 9, taken at exec 9> above) alive after
+    # the detector parent dies, and no replacement instance can ever acquire it.
+    # `9>&-` closes ONLY the child's copy — the parent's lock is unaffected.
     sleep "$interval" 9>&-
   done
 }