NB - Native Browser Bridge

@@ -222,3 +222,21 @@ user's machine at all when you can avoid it. via **ABE** (`chrome.windows.create` FROM INSIDE the running browser — no process launch at all) is strictly safer than any external launch. Extension-free `open_os_window` is the graceful-degradation wedge; ABE is the clean path. Say so.++## ⭐ The badge MUST land on the driven window, never a same-profile PWA (John, 2026-07-21)+The taskbar badge is a SECURITY signal — the user has to know which exact browser window an AI is+driving. It broke because `badgeSpawnsIn` re-correlated a driven session to "the first OS window whose+title contains the profile email" (`profileHwnd`). On a work profile that matches the **"Inbox -[email protected] - Adom Mail"/Gmail PWA** window, so the badge landed on the PWA's taskbar button instead+of the Chrome window the user was watching = the driven window showed NO badge. This is the SAME+wrong-PWA bug that `touchBadge` warns about, reintroduced in the correlation helper. Rules:+- **Correlate each session to its OWN window by the page title, and ONLY match real browser windows**+  (title ends `- Google Chrome` / `- Microsoft Edge`). Never badge by profile-email-in-title — PWAs+  (Adom Mail, Google Messages, Gmail-as-app) carry the email too and are NOT the browser window.+- **Prefer an exact title PREFIX** over a substring: the OS title is `<page title> - <Browser>`, so the+  session's page title is a prefix. Two windows on the same site (e.g. two Gusto pages) share a+  substring but only one is the prefix — prefix-match disambiguates; `matchHwnd` does this now.+- After a bridge RESTART, active sessions lose their captured hwnd; the badge self-heals on the+  session's next drive verb (`touchBadge` → `extQuery(list_windows)` → `badgeSpawnsIn` → `matchHwnd`).+  I restarted the bridge ~20× shipping other fixes that day, so every active thread was un-badged until+  its next verb — expected, but verify the self-heal actually re-correlates to the RIGHT window.