feat: execute durable client commands through supervisor

docs/implementation-plan.v1.md

@@ -1765,6 +1765,24 @@ rows in order. Advertise capacity and accept new dispatch only in `active`.
 Cancellation of one session context must join all its readers/writers before a
 new session can use their queues.
 
+The current implementation checkpoint is intentionally split at this seam:
+`internal/client/agent.RunOnce` owns the reconnect/session reader and remains
+the sole live-session writer; `internal/client/spool` owns the SQLite source of
+truth; and `internal/client/agent.Executor` owns process lifetime independently
+of the WebSocket context. A bounded event-notification channel wakes the active
+writer to assign and send newly appended events, while reconnect replay uses
+the same spool rows and a per-session sent cursor. Every accepted dispatch is
+stored with its deterministic execution specification (and, for scripts, its
+descriptor reservation) before acknowledgement.
+
+Add a schema launch barrier to every implementation of the executor. Persist
+`prepared` before entering the supervisor, persist `authorized` before the OS
+release boundary, and clear it only when a terminal lifecycle transition is
+committed. Startup recovery must convert any non-terminal `authorized` row to
+one `interrupted` event before registering a new network session. This is the
+at-most-once fence for a crash between process release and the first `running`
+event; it is not a substitute for verifying a native process creation identity.
+
 ### 7.2 Output capture and offline caps
 
 Create non-blocking readers for stdout and stderr immediately after process
@@ -1917,6 +1935,15 @@ Implement Windows code in platform-specific files so non-Windows builds never
 import Windows APIs. Keep launch phases identical across platforms:
 `accepted -> launch_prepared -> launch_authorized -> running`, with no shortcut.
 
+The first native adapter is now required to expose this contract through
+`internal/client/supervisor.Supervisor`: the non-Windows adapter is test-only,
+while the Windows implementation must perform token selection and Job setup
+inside the same `Start` call. It may return only after the child has been
+assigned to its kill-on-close Job and released; all token/session attempts must
+be represented in the returned immutable identity. A failed start clears the
+pre-launch barrier and produces one rejected lifecycle event; an uncertain
+authorized row is never retried as a fresh process.
+
 Implement one exhaustive token selector; do not scatter token fallback across
 launch code: