Device picker is active-tab only: background requestDevice fails fast

[davertay-j]

Parent

Sub-issue of #287 (multi-tab support implementation plan).

What to build

Only the currently visible tab may run the Bluetooth device picker. A requestDevice() (or LE-scan picker flow) initiated by a background tab's JS fails fast with a spec-appropriate DOM error instead of presenting UI over an unrelated tab or hanging. This matches Web Bluetooth semantics (user activation + visible document required), so well-behaved sites already handle the rejection. The active tab's picker flow is unchanged, including cancel-on-dismiss when the user switches away mid-selection.

Acceptance criteria

• requestDevice() from a background tab rejects promptly with a spec-appropriate DOM error; no picker UI appears anywhere
• requestDevice() from the active tab works exactly as today (pick, cancel, dismiss-by-swipe)
• Two tabs requesting concurrently can never hang either tab (builds on the selector busy-rejection)
• Gating decisions are unit-tested (active tab passes through, inactive tab rejected); CI green

Blocked by

• DeviceSelector concurrency hardening: reject overlapping selection requests #290 (DeviceSelector concurrency hardening)
• Multi-tab core: switching tabs preserves page state and BLE connections #291 (Multi-tab core)