feat(core): add waitForReady option to launchApp to avoid first-render flakiness

[krismuhi]

Problem

launchApp() resolves as soon as the OS acknowledges the launch. On cold start, the app hasn't rendered its first screen yet, causing the immediately-following assertion to fail. This is especially visible on first run after boot.

Observed in practice: a test checking for a welcome screen text timed out at 27 s on first run, then passed reliably (5–8 s) on subsequent warm runs. The beforeEach did await device.launchApp(bundleId) followed immediately by await expect(screen.getByText('Welcome to Milliways')).toBeVisible().

Fix

Opt-in waitForReady on LaunchOptions — polls getViewHierarchy() until ≥ 2 visible elements appear, up to a configurable timeout (default 5 s). Timeout is soft: if the app hasn't rendered by then, it resolves anyway and the first assertion produces the real error message.

Usage

```typescript
await device.launchApp('com.example.app', { waitForReady: true });
// or with a custom timeout:
await device.launchApp('com.example.app', { waitForReady: 10_000 });
```

Changes

• packages/protocol/src/types.ts: Added waitForReady?: boolean | number to LaunchOptions
• packages/mobilewright-core/src/device.ts: Implemented pollUntilReady private method; launchApp now calls it when waitForReady is set
• packages/mobilewright-core/src/device.test.ts: New test file covering the polling behaviour, soft timeout, error resilience, and the no-op path when waitForReady is not set

Test plan

• waitForReady: true polls getViewHierarchy() at least once
• Resolves when ≥ 2 visible elements appear in hierarchy
• Resolves immediately when hierarchy is already ready
• Accepts a custom millisecond timeout (waitForReady: 10_000)
• Soft-timeout: resolves without throwing when app never becomes ready
• Continues polling (doesn't crash) when getViewHierarchy throws during early startup
• Does not poll at all when waitForReady is not set

[gmegidish]

I think the bug report is correct, launchApp should wait for getForegroundApp to be the same bundleId as what we were launching, and if it fails within the time limit, then we need to throw an exception.

The code commit seems to be related to node modules. But I'll fix the launchApp. The default should be to auto wait, as with tap and all the rest.