fix(ios): surface devices after camera-permission grant; Android parity

[gdelataillade]

Problem

Reproduced on iOS (0.6.0, real glasses, 2 paired+worn pairs): after the user accepts the Meta AI camera-access prompt, the SDK reports no eligible device — startStreamSession fails with noEligibleDevice, activeDeviceStream never emits a non-nil device, and getDevices() returns 0.

Root cause

The plugin only ever observed the AutoDeviceSelector's activeDeviceStream() — it never subscribed to Wearables.shared.devicesStream() / addDevicesListener. On iOS, Wearables.shared.devices is a cold snapshot that stays warm only while something is actively collecting devicesStream(), and glasses surface in that flow only after a camera-permission grant. The selector is created at registrar time (pre-registration) and can stay blind; with nothing watching the device flow, the post-grant emission was observed by nothing, so the selector never resolved and the snapshot read empty. Meta's canonical iOS sample keeps a devicesStream() subscription alive from configure() onward — that was the missing piece.

Android is structurally different: Wearables.devices is a hot StateFlow (confirmed against the decompiled mwdat-core-0.7.0.aar) and DeviceSelectorBase derives its activeDeviceState as a StateFlow from it, so the selector self-resolves and never goes permanently blind. The cold-snapshot bug doesn't exist there — only the post-grant timing needs parity.

Changes

iOS (MetaWearablesDatPlugin.swift)

• startDeviceListMonitoring() — lifetime devicesStream() subscription started right after configure(); warms a knownDeviceIds cache and deterministically re-warms a blind selector when devices appear.
• Relaunches that subscription on the restartActiveDeviceMonitoring (disconnect/re-register) recovery path.
• requestCameraPermission waits (bounded, 8s) for a device to resolve on a grant; returns early on a routine re-check when no device is present.
• getDevices() reads the warm cache (snapshot fallback only before the first emission).
• Re-entrancy guard on rebuildDeviceSelectorIfBlind (now has concurrent callers).

Android (MetaWearablesDatPlugin.kt) — parity: requestCameraPermission re-kicks active-device/device-state monitoring and bounded-waits for the selector to resolve. No device-list subscription needed (hot StateFlow).

Dart — requestCameraPermission documents the bounded post-grant wait.

Bumps to 0.6.1 + CHANGELOG.

Verification

• flutter build ios --no-codesign → ✅ built
• :flutter_meta_wearables_dat:compileDebugKotlin → ✅ success
• dart analyze → no issues
• Adversarial multi-dimension review (Swift compile / iOS concurrency / Android parity / end-to-end efficacy / contract): 3 low-severity findings, all addressed.

Not yet validated

On-device check with 2 paired+worn pairs (accept prompt → activeDevice non-nil in seconds → startStreamSession(null) succeeds → getDevices() returns 2) — needs a maintainer with hardware.

🤖 Generated with Claude Code

[gdelataillade]

Good catch on the P1 — fixed in 2509544.

knownDeviceIds.isEmpty couldn't tell "not emitted yet" from "confirmed empty," so the already-granted fast path could return before the first devicesStream() emission warmed the selector. Added a didReceiveDeviceListEmission flag (set on each emission, reset when the subscription is relaunched) and gated the early return on it: a pre-first-emission empty cache now falls through to the bounded wait instead of bailing.

The fresh-grant path is unaffected (it never early-returns), and Android needs no equivalent change — it reads Wearables.devices.value, a hot StateFlow that always carries a current confirmed value, so it has no not-emitted-yet state.

Verified flutter build ios --no-codesign still builds clean.