Adom Desktop - Puppeteer Bridge

Suggestion (non-blocking): make browser_raise_os_window / browser_lower_os_window track the window HANDLE per session instead of finding it by title.

Context. These two verbs are AD-core (they shadow pup's fallback handlers). AD locates the OS window by matching the " (session: <id>)" suffix that the pup bridge injects into document.title. That coupling is fragile:

• Right after a navigation, the new page sets its own title BEFORE the bridge re-appends the suffix, so for a brief window the suffix is absent and the verb fails with No visible window with title containing "(session: <id>)". Repro: open a pup window, fire browser_navigate + browser_reload, then immediately browser_raise_os_window → intermittent failure.
• Any page that aggressively rewrites its own title (SPAs, some auth flows) can transiently drop the suffix too.

Bridge-side mitigation already shipped (pup 1.8.17): the suffix is now re-injected at document-start on every navigation via evaluateOnNewDocument, which closes the gap in practice (verified: raise/lower now survive a rapid nav+reload burst with no settle delay). So this is no longer urgent.

The robust fix, if you want to kill the class of bug: AD already returns hwnd in the raise/lower response — so it clearly can resolve the handle. Capture/track the HWND per pup session when the window is created (or resolve it once by title and cache it), and drive raise/lower/foreground by HANDLE, not by re-matching the title on every call. That removes the dependency on the bridge's title suffix entirely and is immune to page title churn.

No action needed from pup either way — filing so the title-lookup fragility is tracked on the AD side.