cookie-import-browser on Windows: misleading "locked" error, v20 CDP fallback times out on Chrome 136+, Opera/Opera GX unsupported

Environment: gstack v1.88.1.0, Windows 11, Chrome 153.0.8010.53, Opera GX (current), browse daemon started via $B.

I tried to get an authenticated $B session on Windows and ran into three separate problems in browse/src/cookie-import-browser.ts. Filing them together because each one pushes you toward the next.

1. "Cookie database is locked" is reported for any copy/open failure

openDbFromCopy() wraps copyFileSync + new Database(tmpPath) in one catch and always throws db_locked ("Chrome may be running. Try closing Chrome first."). With Chrome and Edge not running (no chrome.exe/msedge.exe in tasklist, and the Cookies file readable by other processes), browse cookie-import-browser chrome --domain <d> still returned that message from the compiled daemon.

Calling the same code from source (bun -e "import {importCookies} from './cookie-import-browser.ts' ...") opened the same DB fine and got as far as decryption. So something in the compiled daemon's path fails. I couldn't see what, because the original error is swallowed.

Suggestion: include the underlying error message in the db_locked text (or use a separate code for non-lock failures), and only say "may be running" for EBUSY/SQLITE_BUSY.

2. v20 CDP fallback times out on Chrome 136+

After signing in, the Chrome cookie is App-Bound Encrypted (v20), so the file path can't decrypt it (importCookies → failed: 1). importCookiesViaCdp('chrome', [...]) then fails with:

cdp_timeout: Chrome headless did not start within 15s

This is likely Chrome's change in 136: --remote-debugging-port / --remote-debugging-pipe are ignored when Chrome runs against its default user data directory, as a defence against cookie theft. The fallback depends on exactly that (real User Data dir + debug port), so the debug endpoint never comes up and it times out. If that's right, the fallback can't work on current Chrome, and switching to a pipe (#1136) won't bring it back either.

Suggestion: detect Chrome ≥ 136 and fail fast with a clear message, and point to an alternative (a v10 browser, or /connect-chrome).

3. Opera / Opera GX missing from BROWSER_REGISTRY (same situation as #2938)

Opera and Opera GX are Chromium-based and still use v10 cookies on Windows (DPAPI-protected key in Local State, AES-256-GCM values), which the existing Windows v10 path already handles. Two differences from the current registry entries:

• The data dir is under Roaming AppData, not Local: %APPDATA%\Opera Software\Opera GX Stable\ and %APPDATA%\Opera Software\Opera Stable\. getBaseDir('win32') hard-codes AppData\Local.
• There's no User Data level: the profile is <root>\Default\Network\Cookies, with Local State in <root>.

I verified this with a standalone script that uses the same decryption steps, and got a working authenticated session. With Chrome on v20, Opera was the only Windows browser here that $B could get a session from.

Happy to test a patch.