fix(supervisor): SIGTERM an app's process group on stop, SIGKILL after a 3 s grace

[TeoSlayer]

Stacked on #39 (base fix/stop-app-process-group). Merge #39 first; this PR then retargets to main.

Problem

With #39, every stop still SIGKILLs the app: daemon shutdown (StopPlugins), uninstall, and a rescan that replaces the app. The difference is only that the SIGKILL now reaches the whole group. The app never runs its own shutdown.

For io.pilot.wallet that means:

• In-flight calls are cut between the ledger write and the spend-cap log append.
• The sqlite ledger is never closed.
• app.sock is left on disk.

I drove the supervisor's real spawn() against real wallet binaries and stopped them the way the daemon does (ctx cancel):

supervisor	wallet	exit	stop took	app.sock	wallet logged graceful shutdown complete
#39 (killAppGroup)	catalogue 0.3.3	-1	1.9 ms	left	no
#39 (killAppGroup)	0.4.0 (pilot-protocol/wallet#40)	-1	2.4 ms	left	no
this PR	catalogue 0.3.3	0	20.9 ms	removed	yes
this PR	0.4.0 (pilot-protocol/wallet#40)	0	20.5 ms	removed	yes

Change

cmd.Cancel is now stopAppGroup(cmd.Process, appStopGrace):

1. If the app was already reaped (exec can call Cancel after Wait), it returns os.ErrProcessDone and signals nothing.
2. It SIGTERMs the process group the app leads, falling back to the pid.
3. It polls every 20 ms for up to appStopGrace (3 s) for the app to exit.
4. If the app is still running after that, it calls killAppGroup (fix(supervisor): stopping an app stops the processes it started #39), which SIGKILLs the whole group.

The group is only signalled while the app is unreaped (Process.Signal(0) succeeds), so its pid, which is also the group id, is still held. 3 s fits inside the daemon's 5 s pluginStopTimeout (pilotprotocol cmd/daemon/shutdown.go), and apps are stopped in parallel.

Two small related changes:

• Exit status. A stop now reports the app's real exit status (app=… stopped: exit status 0). Before, it reported wait: context canceled / -1, which also went into the exit audit line.
• watchSocket. It returns when ctx is already cancelled. An app that removes its own socket on SIGTERM is shutting down normally, and should not be reported as a socket-lost event.

Upgrades still don't overlap. A replacing rescan cancels the old instance, and the new instance's spawn runs reapStale first. reapStale matches the old instance's argv (same binary and socket), SIGTERMs it, and waits up to its own 3 s grace before the new one binds the socket.

Tests (zz7_stop_graceful_test.go)

• TestStopLetsAppShutDown: the app traps SIGTERM, records it, removes its socket and exits 0. The stop must deliver SIGTERM, finish well under the grace period, remove the socket, return 0, and take the app's subprocess down too.
  • With the Cancel line reverted to fix(supervisor): stopping an app stops the processes it started #39's killAppGroup it fails: app never received SIGTERM, socket … left behind, spawn returned -1.
• TestStopKillsAppThatIgnoresSIGTERM: the app and its subprocess both ignore SIGTERM. Both must be SIGKILLed once the grace runs out.
  • Without this PR it fails: returned after 1.558ms; expected the 3s grace.
• TestStopAppGroupAlreadyExited: an already-reaped process gives os.ErrProcessDone and nothing is signalled.
• fix(supervisor): stopping an app stops the processes it started #39's TestStopKillsAppSubprocesses and TestKillAppGroupFallsBackToThePid still pass.

Where the tests ran:

• macOS arm64: go test -race ./... passes. The stop, reap and watchSocket tests also pass with -count=3.
• golang:1.25.13-bookworm, linux/arm64 and linux/amd64, each with and without --init: go test -race ./... passes.

Known limit

A subprocess that ignores SIGTERM survives if its group leader exits within the grace period. Once the leader is reaped, its group id is no longer safe to signal, so this PR does not signal it.

🤖 Generated with Claude Code