fix(stop-continuation): persist stop state across user messages (#3276)

The /stop-continuation command was ineffective because the stop-
continuation-guard cleared its stopped state on the very next
chat.message event. Since any user message (including normal chat
after stopping) triggers chat.message, the continuation would
resume immediately.

Root cause: the chat.message handler called clear(sessionID) on
every user message, treating it as a 'user resumed work' signal.
But the user expects /stop-continuation to persist until they
explicitly start work again.

Changes:
- stop-continuation-guard chat.message: no longer clears stop state
- tool-execute-before: /start-work, /ralph-loop, /ulw-loop now
  explicitly clear the stop state (so continuation resumes when
  user intentionally restarts work)
- Updated and added tests: 12 pass (3 new), 125 related tests pass

Closes #3276

src/hooks/stop-continuation-guard/hook.ts

@@ -100,10 +100,16 @@ export function createStopContinuationGuardHook(
   }: {
     sessionID?: string
   }): Promise<void> => {
-    if (sessionID && stoppedSessions.has(sessionID)) {
-      clear(sessionID)
-      log(`[${HOOK_NAME}] Cleared stop state on new user message`, { sessionID })
-    }
+    // Intentionally no-op: stop state should persist across user messages.
+    // Previously this cleared the stop on any new user message, but that caused
+    // /stop-continuation to be ineffective — the user's very next message
+    // (including normal chat) would re-enable continuation.
+    //
+    // Stop state is now only cleared by:
+    // 1. /start-work (or /ulw-loop, /ralph-loop) via explicit clear() call
+    // 2. session.deleted event
+    // 3. Future /resume-continuation command
+    void sessionID
   }
 
   return {