fix: handle broadcast channel lag instead of treating it as stream closure (#797)

The CDP event broadcast channel (capacity 256) can overflow on slow CI
runners when Chrome emits many events during navigation. Previously,
RecvError::Lagged was treated the same as RecvError::Closed, causing
spurious "Event stream closed" errors even though Chrome was still
running. Now all 5 event-receiving loops correctly continue on Lagged
instead of breaking.

cli/src/native/browser.rs

@@ -469,9 +469,17 @@ impl BrowserManager {
         let timeout = tokio::time::Duration::from_millis(self.default_timeout_ms);
 
         tokio::time::timeout(timeout, async {
-            while let Ok(event) = rx.recv().await {
-                if event.method == event_name && event.session_id.as_deref() == Some(session_id) {
-                    return Ok(());
+            loop {
+                match rx.recv().await {
+                    Ok(event) => {
+                        if event.method == event_name
+                            && event.session_id.as_deref() == Some(session_id)
+                        {
+                            return Ok(());
+                        }
+                    }
+                    Err(tokio::sync::broadcast::error::RecvError::Lagged(_)) => continue,
+                    Err(tokio::sync::broadcast::error::RecvError::Closed) => break,
                 }
             }
             Err("Event stream closed".to_string())
@@ -526,6 +534,7 @@ impl BrowserManager {
                         }
                     }
                     Ok(Ok(_)) => {}
+                    Ok(Err(tokio::sync::broadcast::error::RecvError::Lagged(_))) => continue,
                     Ok(Err(_)) => break,
                     Err(_) => {
                         // Timeout on recv -- check if idle long enough