Windows stop.bat shutdown path is still unreliable/goofy

[SymbioSyncProject]

Summary

stop.bat exists, but shutdown behavior is still not reliable enough to consider done.

Observed behavior

• stop.bat can stop some running SymbioSync server processes.
• In ordinary use it may still feel goofy or unreliable.
• After shutdown, the browser tab remains open and shows blinking server-unreachable state. That part is good.

Expected behavior

Windows users should have a clear, reliable shutdown path that:

1. sends best-effort /api/stop for connected devices,
2. stops the local SymbioSync server process,
3. leaves the UI in an honest unreachable state or gives clear next steps,
4. does not kill unrelated Python processes.

Truth/safety impact

Medium. Shutdown ambiguity can leave users unsure whether the bridge is still running or devices were stopped. The UI must not imply the server is reachable when it is gone.

Notes

The current blinking server unreachable browser state is desirable. Preserve it.

Acceptance criteria

• Repro matrix for stop.bat: no server, default port, custom port, server launched by start.bat, server launched by python -m symbiosync.
• Process matching is safe and documented.
• User-facing shutdown instructions are clear.

[SymbioSyncProject]

Related startup/stop improvement landed in 0222e04.

python -m symbiosync now checks the target port before uvicorn tries to bind:

• if port 8080 already has a reachable SymbioSync server, startup opens/reuses the existing server and exits cleanly
• if port 8080 is occupied but /api/status does not answer, startup reports the wedged/foreign process clearly instead of dumping the uvicorn bind traceback
• start.bat copy was updated to explain this behavior

This does not fully close the goofy Windows shutdown path. It makes the common "already running / stale process holds port" failure mode more truthful and less ugly. stop.bat still deserves its own follow-up hardening.