Description

`openclaw gateway stop` returns successfully (with the message "Stopped LaunchAgent (degraded)") but the underlying `node` process hosting the gateway continues to run. This wedged process keeps the gateway port bound and prevents a clean restart.

Evidence

After running `openclaw gateway stop`:

Warning: launchctl stop did not fully stop the service; 
used bootout fallback and left service unloaded
Stopped LaunchAgent (degraded): gui/501/ai.openclaw.gateway

But `pgrep -fl openclaw-gateway` still shows the original process running:

$ ps -o pid,etime,command -p $(pgrep -f openclaw-gateway)
  PID  ELAPSED COMMAND
69772 01:21:52 openclaw-gateway OPENCLAW_SERVICE_VERSION=2026.4.25

The process has 1h 21min uptime — confirming it survived multiple `openclaw gateway stop` calls.

Impact

This is particularly bad during version rollback:

1. User runs `openclaw gateway stop` (returns success, but actual process keeps running)
2. User runs `npm i -g openclaw@` (replaces files on disk)
3. The still-running old process now references files that have been replaced
4. New gateway start attempt fails: `EADDRINUSE: address already in use 127.0.0.1:18790` — held by the old process
5. `/health` returns 500 or hangs because the old process is referencing missing modules

The user has to manually `kill -9 $(pgrep -f openclaw-gateway)` to recover.

Steps to Reproduce

1. Start gateway with `openclaw gateway start` (running for some time)
2. Run `openclaw gateway stop`
3. Check `pgrep -fl openclaw-gateway` — process is still running

Suggested Fix

`openclaw gateway stop` should:

1. Send SIGTERM and wait up to N seconds for graceful shutdown
2. If process still alive, send SIGKILL
3. Verify the port is free before returning success
4. If after the kill the port is still bound, return a non-zero exit code with a clear error

"Stopped (degraded)" is misleading — to the user, this looks like success, but functionally the gateway is still running.

Workaround

openclaw gateway stop
sleep 2
kill -9 $(pgrep -f openclaw-gateway) 2>/dev/null
sleep 2
lsof -iTCP:18790 -sTCP:LISTEN -nP   # verify port is free
openclaw gateway start

Recurring Pattern

This is the third time we've hit this in 6 weeks (during the 4.10 saga, the 4.15 transition, and now the 4.25 rollback). Every time the fix has been to manually `kill -9` the wedged process. Worth fixing because it makes "safe" stop operations not actually safe.

Environment

• OpenClaw 2026.4.23, 2026.4.25 (both versions affected)
• macOS 26.3.1 (arm64), Node 25.8.0