Missing port-release verification after force-kill

The original code had a second waitForGatewayPortRelease(restartPort, 2_000) guard after calling terminateBusyPortListeners. That 2-second check was the only mechanism that confirmed the port was actually free before the task was scheduled to start again. It has been removed here without a replacement.

The detached restart script's retry loop only re-runs schtasks /Run if the command itself fails (e.g. the task is still in a "stopping" state). It has no awareness of port availability. If schtasks /Run succeeds but the gateway process can't bind the port because a listener was not yet fully released, the gateway will exit immediately and silently — and the retry loop won't fire again because the initial schtasks /Run call returned exit code 0.

Consider restoring the port-release guard (or an equivalent check) before the function returns, for example:

if (restartPort) {
  const released = await waitForGatewayPortRelease(restartPort);
  if (!released) {
    await terminateBusyPortListeners(restartPort);
    const releasedAfterForce = await waitForGatewayPortRelease(restartPort, 2_000);
    if (!releasedAfterForce) {
      // Port still busy; the detached script will likely start a gateway that can't bind.
      // Log a warning, or throw so the caller surfaces the issue.
    }
  }
}

This is a comment left during a code review.
Path: src/daemon/schtasks.ts
Line: 727-730

Comment:
**Missing port-release verification after force-kill**

The original code had a second `waitForGatewayPortRelease(restartPort, 2_000)` guard after calling `terminateBusyPortListeners`. That 2-second check was the only mechanism that confirmed the port was actually free *before* the task was scheduled to start again. It has been removed here without a replacement.

The detached restart script's retry loop only re-runs `schtasks /Run` if the command itself fails (e.g. the task is still in a "stopping" state). It has no awareness of port availability. If `schtasks /Run` succeeds but the gateway process can't bind the port because a listener was not yet fully released, the gateway will exit immediately and silently — and the retry loop won't fire again because the initial `schtasks /Run` call returned exit code 0.

Consider restoring the port-release guard (or an equivalent check) before the function returns, for example:

```typescript
if (restartPort) {
  const released = await waitForGatewayPortRelease(restartPort);
  if (!released) {
    await terminateBusyPortListeners(restartPort);
    const releasedAfterForce = await waitForGatewayPortRelease(restartPort, 2_000);
    if (!releasedAfterForce) {
      // Port still busy; the detached script will likely start a gateway that can't bind.
      // Log a warning, or throw so the caller surfaces the issue.
    }
  }
}
```

How can I resolve this? If you propose a fix, please make it concise.

Potentially unreachable cleanup code

The PR description states: "schtasks /End terminates the current process immediately" — yet all four cleanup steps (terminateScheduledTaskGatewayListeners, terminateInstalledStartupRuntime, waitForGatewayPortRelease, terminateBusyPortListeners) sit after the /End call and would never run if the process is killed synchronously.

If the process is indeed killed immediately on Windows, these lines are dead code in the common path, and any cleanup they were meant to do (releasing port listeners, stopping the startup runtime) is skipped entirely. The detached restart script then races against those still-running resources.

Consider either:

• Moving critical cleanup steps before execSchtasks(["/End", …]) (mirrors what relaunchGatewayScheduledTask itself does by spawning before ending), or
• Adding a brief comment explaining these are intentionally best-effort and may not execute.

This is a comment left during a code review.
Path: src/daemon/schtasks.ts
Line: 723-731

Comment:
**Potentially unreachable cleanup code**

The PR description states: *"`schtasks /End` terminates the current process immediately"* — yet all four cleanup steps (`terminateScheduledTaskGatewayListeners`, `terminateInstalledStartupRuntime`, `waitForGatewayPortRelease`, `terminateBusyPortListeners`) sit after the `/End` call and would never run if the process is killed synchronously.

If the process is indeed killed immediately on Windows, these lines are dead code in the common path, and any cleanup they were meant to do (releasing port listeners, stopping the startup runtime) is skipped entirely. The detached restart script then races against those still-running resources.

Consider either:
- Moving critical cleanup steps **before** `execSchtasks(["/End", …])` (mirrors what `relaunchGatewayScheduledTask` itself does by spawning before ending), or
- Adding a brief comment explaining these are intentionally best-effort and may not execute.

How can I resolve this? If you propose a fix, please make it concise.

Re-check port release before marking restart complete

This restart path now stops after terminateBusyPortListeners(restartPort) without verifying that the gateway port was actually freed, then reports success. In cases where a listener cannot be killed (for example, permission-restricted PID or a non-gateway process holding the port), the detached helper still calls schtasks /Run; that command can return success even if the gateway immediately dies on bind, so users get a false "Restarted" result and the service stays down. The previous logic explicitly re-waited and threw when the port remained busy.

Useful? React with 👍 / 👎.

Validate task stop before reporting restart success

restartScheduledTask now unconditionally reports success right after execSchtasks(["/End", ...]), but it no longer checks any synchronous /Run result in this code path. When task control actually fails (for example, ACL-denied task control, or the task being removed/disabled between the earlier existence check and restart), the detached helper can fail silently and this function still returns { outcome: "completed" } with "Restarted Scheduled Task", which is a regression from the prior behavior that surfaced restart failures via the inline /Run status check.

Useful? React with 👍 / 👎.

Spawn restart handoff before pre-end listener termination

restartScheduledTask now terminates gateway listeners before calling relaunchGatewayScheduledTask, which can kill the current process in the exact Windows fallback case where verified PID discovery misses. resolveScheduledTaskGatewayListenerPids falls back to inspectPortUsage and does not filter out process.pid, so when restart is triggered from the running scheduled-task gateway, terminateScheduledTaskGatewayListeners can end the caller before the detached /Run script is created, leaving the task stopped with no relaunch attempt.

Useful? React with 👍 / 👎.

Provide inline /Run fallback when handoff setup fails

In restartScheduledTask, all stop/cleanup work runs before this check, so when relaunchGatewayScheduledTask returns ok: false (for example, temp script write/spawn failures handled in src/infra/windows-task-restart.ts), this throw aborts without any /Run attempt and can leave the gateway down after a restart request. This regression is specific to environments where detached-script setup fails, and an inline /Run fallback (when still possible) would avoid turning a transient handoff error into an outage.

Useful? React with 👍 / 👎.