fix(#863): belt-and-suspenders Windows console hide + JS error surfacing

User reported on Windows + Claude Desktop that even after the pythonw
fix in b0268d7, the cmd window still pops AND the settings page
still says "Loading..." indefinitely.

**Windows console:** add ``STARTUPINFO`` with ``wShowWindow=SW_HIDE``
on top of pythonw preference + ``CREATE_NO_WINDOW``. uv-managed
Pythons sometimes strip pythonw.exe, falling back to python.exe.
``CREATE_NO_WINDOW`` alone leaves a window in some console-allocation
paths under GUI parents; ``STARTF_USESHOWWINDOW`` + ``SW_HIDE``
force-hides whatever console does get allocated.

**JS error surfacing:** if any function definition in the settings-
page script throws during top-level evaluation (e.g. a runtime error
referencing a missing DOM element), the script aborts before
``loadTools()`` is ever called and the status bar stays at the
initial ``Loading...`` literal. Add ``window.addEventListener('error',
...)`` + ``unhandledrejection`` so the next time the page hangs at
"Loading", the actual error message appears in the status bar
instead — no devtools required.

Author: kingpanther13

src/ha_mcp/settings_ui.py

@@ -529,6 +529,24 @@ def apply_tool_visibility(
 <input type="text" class="search" id="search" placeholder="Search tools...">
 <div id="groups"></div>
 <script>
+// Catch top-level / async script errors and surface them in the
+// status bar so a perpetually-"Loading" page becomes self-diagnosing
+// (no devtools required). Without this, a script-evaluation error
+// in any of the function definitions below would abort the script
+// before loadTools() is even called, leaving the status stuck at
+// the initial "Loading...".
+window.addEventListener('error', (e) => {
+  const el = document.getElementById('status');
+  if (!el) return;
+  const where = e.filename ? `${e.filename}:${e.lineno}:${e.colno}` : 'inline';
+  el.textContent = `JS error: ${e.message} @ ${where}`;
+});
+window.addEventListener('unhandledrejection', (e) => {
+  const el = document.getElementById('status');
+  if (!el) return;
+  el.textContent = `Async error: ${e.reason && e.reason.message ? e.reason.message : String(e.reason)}`;
+});
+
 let toolData = [];
 let toolStates = {};
 let saveTimer = null;

src/ha_mcp/stdio_settings_sidecar.py

@@ -318,30 +318,31 @@ def _do_spawn() -> None:
         "close_fds": True,
     }
     if sys.platform == "win32":
-        # Prefer ``pythonw.exe`` over ``python.exe``. pythonw is the
-        # GUI-subsystem Python interpreter — Windows never allocates a
-        # console window for it. Falls back to python.exe if pythonw
-        # isn't alongside (rare; most CPython distributions ship both,
-        # including the uv-installed Python that uvx uses).
+        # Three-layer defense against the cmd-window-pops-and-closing-
+        # it-kills-the-server bug reported against Claude Desktop:
         #
-        # Why not DETACHED_PROCESS: the prior attempt used
-        # ``DETACHED_PROCESS | CREATE_NEW_PROCESS_GROUP | CREATE_NO_WINDOW``
-        # and the cmd window still popped under Claude Desktop. Python's
-        # subprocess docs spell out that ``CREATE_NO_WINDOW`` is
-        # IGNORED when ``DETACHED_PROCESS`` is set, and
-        # ``DETACHED_PROCESS`` on a CUI binary auto-allocates a fresh
-        # visible console. pythonw avoids the whole console-allocation
-        # path.
+        # 1. Prefer ``pythonw.exe`` over ``python.exe``. pythonw is the
+        #    GUI-subsystem Python — Windows never allocates a console
+        #    for it. Falls back to python.exe if pythonw isn't there
+        #    (uv-installed Pythons sometimes strip it).
+        # 2. ``STARTUPINFO`` with ``SW_HIDE`` forces any console that
+        #    DOES get allocated to be hidden. Catches the fallback case.
+        # 3. ``CREATE_NO_WINDOW`` suppresses console allocation entirely
+        #    for the python.exe fallback. ``CREATE_NEW_PROCESS_GROUP``
+        #    prevents a CTRL_CLOSE_EVENT (X-button on any console that
+        #    sneaks through) from killing the sidecar.
         #
-        # CREATE_NEW_PROCESS_GROUP is still useful: closing any console
-        # that happens to be attached (if pythonw isn't found and we
-        # fall back to python.exe) sends ``CTRL_CLOSE_EVENT`` to the
-        # console's process group. Putting the child in its own group
-        # prevents that event from killing the sidecar.
-        # CREATE_NO_WINDOW is belt-and-suspenders for the python.exe
-        # fallback path — harmless when pythonw is in use.
+        # Why not DETACHED_PROCESS: prior attempts used it, but Python's
+        # docs spell out that ``CREATE_NO_WINDOW`` is IGNORED when
+        # DETACHED_PROCESS is set, and DETACHED_PROCESS on a CUI binary
+        # auto-allocates a fresh visible console — the exact failure
+        # mode the user saw.
         pythonw = Path(sys.executable).with_name("pythonw.exe")
         cmd_python = str(pythonw) if pythonw.exists() else sys.executable
+        startupinfo = subprocess.STARTUPINFO()  # type: ignore[attr-defined]
+        startupinfo.dwFlags |= subprocess.STARTF_USESHOWWINDOW  # type: ignore[attr-defined]
+        startupinfo.wShowWindow = subprocess.SW_HIDE  # type: ignore[attr-defined]
+        popen_kwargs["startupinfo"] = startupinfo
         popen_kwargs["creationflags"] = (
             subprocess.CREATE_NEW_PROCESS_GROUP  # type: ignore[attr-defined]
             | subprocess.CREATE_NO_WINDOW  # type: ignore[attr-defined]