DeviceSelector concurrency hardening: reject overlapping selection requests

[davertay-j]

Parent

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

What to build

Make the shared device selector safe under concurrent use. Today a second selection request silently overwrites the in-flight continuation, leaking it and leaving the first requester's promise hung forever — unreachable with a single tab, but reachable once multiple tabs are live (and the existing code carries a TODO about exactly this).

A selection request arriving while another is in flight must fail fast with a distinct "busy" error, leaving the in-flight selection untouched.

Acceptance criteria

• A second concurrent selection request immediately receives a "busy"-style failure; the first request's flow is unaffected and resolves normally
• No continuation is ever leaked or double-resumed (covered by unit tests, resolving the existing TODO)
• Existing single-selection behavior unchanged: user pick, explicit cancel, and dismiss-by-swipe all resolve as today
• Unit tests pass in CI

Blocked by

• None — can start immediately.