fix: prevent infinite poll loop on unresponsive browser contexts

[joaocarlos]

Summary

Fixes the infinite/high-CPU polling loop described in #16 when NotebookLM browser context enters a zombie/unresponsive state.

Root Cause

waitForLatestAnswer() relied on page.waitForTimeout(pollIntervalMs) to pace polling. When the browser/page is unhealthy, this wait can return immediately, turning the loop into a hot spin.

Changes

• Added centralized recoverable browser error detection:
  • src/utils/browser-errors.ts
• Hardened waitForLatestAnswer() in src/utils/page-utils.ts:
  • safe minimum poll interval
  • hard poll-count guard (maxPolls)
  • fallback Node sleep when waitForTimeout returns too early
  • periodic page health checks (page.evaluate(() => true) + timeout)
• Stopped swallowing recoverable browser errors in extraction paths so failures bubble up and trigger session recovery.
• Updated session recovery in src/session/browser-session.ts:
  • use shared recoverable error matcher for newPage, ask, and reset recovery paths
  • recover on unresponsive/disconnected states, not only explicit “closed” states

Validation

• npm run build passes.
• Local MCP stdio integration against node dist/index.js:
  • get_health OK
  • list_notebooks OK
  • real ask_question calls OK
  • same-session follow-up verified (session_id unchanged, message_count = 2)
• Synthetic zombie-page test:
  • simulated waitForTimeout immediate return + hanging evaluate
  • exits quickly with: Browser page unresponsive: health check timed out...
  • no infinite spin observed

Issue

Closes #16