docs(v0.6): record Phase 3 binary smoke result in notes

notes.md

@@ -357,11 +357,22 @@ scaffolding) was already delivered in Phase 2 commit `0c6ed0c`, so §9
 - `just build` — `ctask.exe` (PE32+ x86-64).
 - `just build-linux` — `dist/ctask-linux-amd64`, statically linked ELF
   (the only check that compiles `pidcheck_unix.go`).
-- Manual interactive smoke (Ctrl-C a live session then immediate
-  `ctask resume`; stale display in `info`/`list`) — **pending**: requires
-  a real TTY + agent session and was deferred to hands-on review. The
-  behavior is covered deterministically by `TestInspectLeaseDeadLocalPIDIsStale`,
-  the `TestIsStale*` matrix, and the `TestCheckProcess*` real-syscall tests.
+- Binary smoke (v0.6.0 `ctask.exe`, real workspaces under a temp
+  `CTASK_ROOT`) — **passed**. A lease carrying a reaped, genuinely-dead
+  owner PID, the real host's hostname, and a 9-second-old heartbeat
+  (unambiguously wall-clock-fresh) was auto-cleaned by `ctask resume`
+  with `[ctask] Cleaned up stale session … last seen 9s ago` — no
+  Layer-1 "Continue anyway?" prompt, no 60s wait, resume proceeded
+  (exit 0). `ctask info` / `ctask list` on the same kind of lease report
+  `stale` (they are read-only — they do not remove it). The dead PID
+  alone (not wall-clock age) drove the staleness, confirming PID
+  liveness end-to-end in the shipped binary.
+- Smoke finding worth keeping: on Windows, if another process holds an
+  open handle to the dead owner (e.g. a parent that has not yet reaped
+  it), `OpenProcess` still succeeds and `defaultCheckProcess` returns
+  `ProcessAlive` — the documented conservative "zombie handle" case. The
+  lease then falls back to wall-clock. The real Ctrl-C / terminal-close
+  path has no such lingering handle, so PID liveness fires as intended.
 
 #### Phase 3 constraints held