Widen session.start browser-connect wait for cold reconnects

After a long idle the service worker is only revived on its next
keepalive-alarm tick (up to 30s away), so the previous 5s wait made
the first command after idle fail with `no_browser_connected` even
though the extension was about to reconnect.

- Raise the daemon's `EXTENSION_CONNECT_WAIT` (used by `session.start`)
  to 35s so it comfortably covers one alarm period plus handshake slack.
- Bump the CLI `session start` IPC timeout to that window plus slack so
  it never gives up before the daemon answers, and print a one-line
  "waiting for browser extension to connect…" hint when it actually
  waits.
- Keep `bsk status` / `browsers` on their own short 5s wait so quick
  informational commands are not slowed down.

Co-authored-by: Cursor <cursoragent@cursor.com>

crates/bsk-cli/src/cli/browser_wait.rs

@@ -2,10 +2,16 @@
 
 use std::time::Duration;
 
-use crate::daemon::browsers::EXTENSION_CONNECT_WAIT;
-
 /// Default wait passed to daemon status/list RPCs when the registry is empty.
-pub const DEFAULT_BROWSER_CONNECT_WAIT: Duration = EXTENSION_CONNECT_WAIT;
+///
+/// Deliberately shorter than the daemon's [`EXTENSION_CONNECT_WAIT`]
+/// (used by `session.start`): `bsk status` / `bsk browsers` are quick
+/// informational snapshots, so blocking them for a full keepalive-alarm
+/// period would hurt more than it helps. The long wait is reserved for
+/// the command path that actually needs the extension online.
+///
+/// [`EXTENSION_CONNECT_WAIT`]: crate::daemon::browsers::EXTENSION_CONNECT_WAIT
+pub const DEFAULT_BROWSER_CONNECT_WAIT: Duration = Duration::from_secs(5);
 /// Keep CLI-side waits aligned with the daemon's IPC clamp so a bad env value
 /// cannot inflate read timeouts after the daemon has already returned.
 const MAX_BROWSER_CONNECT_WAIT: Duration = Duration::from_secs(60);