fix(settings-ui): preserve search filter across tool-toggle rebuilds

Reported: typing a query in the Tools tab search bar filtered the
list correctly, but toggling a setting on a visible tool snapped the
full list back into view — even though the search bar still showed
the query.

Root cause: ``render()`` (called after every toggle change via
``scheduleSave(); render();``) does ``container.innerHTML = ''`` and
rebuilds the entire ``.tool`` DOM. The search filter applied the
``hidden`` class imperatively to the OLD nodes; the freshly-built
nodes had none. The ``<input>`` element itself is outside the
rebuilt container, so its value persists — producing the
visible-query-but-no-filter mismatch the user reported.

Fix: extract the filter into ``applyToolSearch()`` that reads the
search input's current value directly and applies / clears the
``hidden`` class on every ``.tool`` node it finds. Wire it to the
input's ``input`` event (was inline before) and also call it at the
end of ``render()`` so any rebuild — toggle change, group-master
toggle, future render triggers — re-applies the active filter
against the new DOM.

No regression risk on the no-search path: an empty query short-
circuits ``!q`` to true and every tool stays visible, same outcome
as before. Group auto-expansion when search has matches still
works (q && visible branch unchanged).

Not directly testable in the current JS test infra (the project
bar is ``node --check`` syntax-only — no JSDOM, no DOM event
simulation). Closing that gap is tracked in #1422; ``node --check``
on the rebuilt script confirms no syntax regression.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: kingpanther13

src/ha_mcp/settings_ui.py

@@ -1298,6 +1298,15 @@ def apply_tool_visibility(
     `<span style="color:var(--success)">${enabledCount} enabled</span>` +
     `<span style="color:var(--accent)">${pinnedCount} pinned</span>` +
     `<span style="color:var(--danger)">${disabledCount} disabled</span>`;
+
+  // ``render()`` rebuilds the entire ``.tool`` DOM, so any
+  // ``hidden`` class previously applied by ``applyToolSearch`` is
+  // wiped. The search ``<input>`` is a separate element and keeps
+  // its value across the rebuild — re-apply the filter so the
+  // visible list matches what the user has typed. Otherwise
+  // toggling a setting on a filtered tool snaps the full list back
+  // even though the search box still shows the query.
+  applyToolSearch();
 }
 
 function scheduleSave() {
@@ -1331,8 +1340,12 @@ def apply_tool_visibility(
   el.className = saved ? 'status saved' : 'status';
 }
 
-document.getElementById('search').addEventListener('input', (e) => {
-  const q = e.target.value.toLowerCase();
+function applyToolSearch() {
+  // Read the current search query directly from the DOM rather than
+  // taking it as a parameter — ``render()`` calls this after rebuilding
+  // the tool DOM and needs to use whatever the user currently has
+  // typed without coordinating with the input event.
+  const q = (document.getElementById('search').value || '').toLowerCase();
   document.querySelectorAll('.tool').forEach(el => {
     const match = !q || el.dataset.name.includes(q) || el.dataset.title.includes(q);
     el.classList.toggle('hidden', !match);
@@ -1346,7 +1359,9 @@ def apply_tool_visibility(
       g.querySelector('.group-chevron').classList.add('open');
     }
   });
-});
+}
+
+document.getElementById('search').addEventListener('input', applyToolSearch);
 
 document.getElementById('restartBtn').addEventListener('click', restartAddon);