fix(cdp): fast-path Target.getBrowserContexts for Puppeteer connect (#120)

Puppeteer's first CDP call after connect is Target.getBrowserContexts.
When the single cdp_processor is busy (e.g. Page.navigate with fetch
interception), queued Target commands stall and Puppeteer hits
protocolTimeout on getBrowserContexts before any user code runs.

Answer getBrowserContexts synchronously in fast_path_response with the
same payload as domains::target::handle (default context id "default"),
matching Browser context initialization in CdpContext.

Co-authored-by: Obscura Contributor <contributor@users.noreply.github.com>

crates/obscura-cdp/src/server.rs

@@ -502,6 +502,15 @@ fn fast_path_response(text: &str) -> Option<String> {
         "Browser.setDownloadBehavior" | "Browser.getWindowBounds" => {
             Some(json!({}))
         }
+        // Critical: Puppeteer calls this as the *first* CDP command on connect
+        // (`BrowserConnector._connectToCdpBrowser`). If another client or a long
+        // `Page.navigate` / interception holds the single `cdp_processor` task,
+        // queued Target commands starve and Puppeteer hits protocolTimeout on
+        // `Target.getBrowserContexts`. Fast-path bypasses the queue — same payload
+        // as `domains::target::handle` when default context id is `"default"`.
+        "Target.getBrowserContexts" => {
+            Some(json!({ "browserContextIds": ["default"] }))
+        }
         _ => None,
     };