[Windows] SIGUSR1 restart spawns a second visible cmd.exe gateway.cmd window (v4.5+)

Summary

On Windows, when a SIGUSR1 restart is triggered (e.g. via config.patch), the gateway spawns two processes:

1. schtasks /Run /TN "OpenClaw Gateway" — the scheduled task supervisor (correct)
2. cmd.exe /k gateway.cmd directly — a second visible console window that then fails because port 18789 is already taken

The second window appears on screen (visibly), flashes the gateway startup output, hits "port in use", and lingers until its node child exits. This is disruptive for users who run the gateway in a visible console (e.g. pinned to a secondary monitor).

Steps to reproduce

1. Have an active gateway running on Windows with the OpenClaw Gateway scheduled task configured
2. Trigger a SIGUSR1 restart (e.g. via openclaw config.patch with any value, or openclaw restart)
3. Observe: a second cmd.exe window appears with gateway startup output, then fails on port conflict

Expected behaviour

Only one gateway process starts. The scheduled task supervisor handles the restart without spawning an additional visible console.

Actual behaviour

Two processes attempt to start. The second (direct cmd.exe /k gateway.cmd fallback) creates a visible window, tries to bind port 18789, fails, and eventually exits. The window may stay on screen for 5–30 seconds.

Environment

• OpenClaw: v2026.4.5
• OS: Windows 10 x64 (build 19045)
• Node: v24.6.0
• Gateway mode: local, bind: loopback
• OpenClaw Gateway scheduled task configured (LogonTrigger, InteractiveToken)

Workaround

Add a port-check guard at the top of gateway.cmd that self-hides and exits if port 18789 is already listening:

powershell -NoProfile -NonInteractive -Command "if (Get-NetTCPConnection -LocalPort 18789 -State Listen -ErrorAction SilentlyContinue) { ... exit 1 } else { exit 0 }"
if errorlevel 1 exit /b 0

However, openclaw doctor --fix regenerates gateway.cmd and wipes this guard, so it must be re-applied after every upgrade.

Additional context

This appears to be a regression introduced in one of the v2026.3.x–v2026.4.x releases. The restart comment in the generated gateway.cmd mentions OPENCLAW_WINDOWS_TASK_NAME=OpenClaw Gateway, suggesting the intent was to use schtasks exclusively — but the direct fallback spawn also fires on Windows. The root fix would be to suppress or skip the direct cmd.exe /k gateway.cmd fallback spawn on Windows when a task name is configured, or to not spawn it at all when the scheduled task is the intended restart mechanism.