daemon status --json reports runtime.status=stopped while port 18789 still has a listener (split-brain)

Summary

openclaw daemon status --json reports runtime.status=stopped even when port 18789 has an active listener owned by a previous gateway instance. The status reporter is reading service-registration state and not cross-checking the actual port owner, so it lies in any split-brain scenario.

Repro

Easiest path is via the companion bug (#979 — gateway install --force not idempotent):

1. Have a healthy gateway running and listening on 18789
2. Run openclaw gateway install --force → second instance fails with EADDRINUSE, but the first instance keeps running
3. Run openclaw daemon status --json

Observed

{ \"runtime\": { \"status\": \"stopped\" }, ... }

…while netstat -ano | findstr 18789 shows the original node.exe still listening.

Expected

The status reporter should cross-check:

• Is port 18789 currently bound? (if yes, by which PID?)
• Is the bound PID one of our managed gateway instances?

Possible reported states:

At minimum, conflict is needed so downstream tooling can distinguish "daemon is genuinely down" from "daemon is in split-brain after a botched install".

Impact

Discovered during downstream verification (anro-claw issue #825). Downstream L2 acceptance tests trust daemon status --json as the ground-truth health probe — when it lies, real env state gets mis-framed as a regression. We currently work around it by checking netstat 18789 directly, but that's not portable and shouldn't be necessary.

Environment

• Windows 11, Node 20 (bundled)
• Observed on 5060Ti, 2026-04-26

Start at the implementation of openclaw daemon status --json and reproduce the split-brain case with a listener on port 18789. Trace how service-registration state is read and how the port owner is detected across the stated Windows environment. Done means the JSON distinguishes running, stopped, conflict with the offending PID, and stale as specified.