fix(update): the legacy start_watchdog starts the monitor in its own process group; tests clean up only the processes they started (Issue #72, review round 5)

With MAM_DELEGATION_PY=0 the monitor was left in the caller's process group
(decision 2), on every restart the update makes. The legacy body now spawns
it under job control (`set -m`, macOS has no setsid(1)) and restores the
caller's option. The update tests assert the restarted monitor's PGID in both
modes, and their teardown kills helper groups and this test's exact monitors
instead of `pkill -f <ws>`, then reports anything left that names the
workspace.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

.agents/skills/lib.sh

@@ -2297,10 +2297,16 @@ _start_watchdog_legacy() {
   elif [ -z "$pid" ]; then
     # Start the wildcard monitor subscriber daemon with --idle-timeout 0 (never idle out)
     # and ensure it runs with $workdir as cwd to anchor relative log paths.
-    local orig_pwd="$PWD"
+    # Issue #72 (decision 2): job control (`set -m`) starts it in its own
+    # process group, out of the caller's, as the python body's new session
+    # does; macOS has no setsid(1). The caller's option is restored.
+    local orig_pwd="$PWD" had_m=0
+    case $- in *m*) had_m=1 ;; esac
     cd "$workdir" || return 1
+    set -m
     nohup bash "$monitor_script" --subscribe --idle-timeout 0 </dev/null >> "$log_file" 2>&1 &
     pid=$!
+    [ "$had_m" = 1 ] || set +m
     cd "$orig_pwd" || return 1
   fi