fix(browser): make waitFor options explicit and race-safe #110

Problem

Session.waitFor currently has the positional signature waitFor(method, predicate?, timeoutMs?). The natural call shape waitFor(method, { timeoutMs: 15000 }) treats the options object as a predicate. When an event arrives, that object is called as a function; the event-dispatch loop swallows the resulting listener exception, so the event is lost and the default timeout eventually fires.

The browser-execute skill also demonstrates Page.navigate() followed by waitFor("Page.loadEventFired"). A fast load event can arrive before the listener is registered.

Minimal reproduction

const waiting = session.waitFor(
  "Page.loadEventFired",
  { timeoutMs: 20 },
)

// Deliver Page.loadEventFired here. The event is discarded and `waiting` times out.

The same missed-event behavior can be reproduced by delivering the event immediately after Page.navigate() resolves but before calling waitFor().

Proposed fix

• Support and document an options form such as waitFor(method, { predicate?, timeoutMs? }), while retaining the existing positional form if compatibility requires it.
• Validate argument types immediately instead of treating arbitrary truthy values as predicates.
• If a predicate throws, unsubscribe and reject that waiter; do not swallow the exception and continue waiting.
• Update the navigation example to register the waiter before invoking Page.navigate().
• Add deterministic unit tests for the options form, custom timeout, predicate failure, and an event emitted during navigation.

This issue intentionally describes the general API behavior only.