feat(app): preserve multiple saved devices

[moni11811]

Theory
Multi-device support failed because the app persisted one active BLE device and the onboarding scanner rendered only live scan results. A second saved device displaced the first, and offline saved devices disappeared from the connect flow.

Scope

• Adds SharedPreferencesUtil.btDevices list storage with legacy btDevice fallback.
• Keeps btDeviceSet updating active device while preserving unique saved devices.
• Adds OnboardingProvider.savedDeviceList and visibleDeviceList.
• Updates Find Devices UI to render saved offline devices and replace them with live scan data when seen.

Cut from #9084

• Meta glasses provider/page/runtime.
• On-device transcription.
• Android/iOS native recording churn.
• Docs/plugin examples/auth changes.

Tests

• Red first: flutter test test/providers/onboarding_provider_multi_device_test.dart failed on missing btDevices, savedDeviceList, and visibleDeviceList.
• Green: flutter test test/providers/onboarding_provider_multi_device_test.dart.
• Green: dart analyze lib/backend/preferences.dart lib/providers/onboarding_provider.dart lib/pages/onboarding/find_device/found_devices.dart test/providers/onboarding_provider_multi_device_test.dart.

Notes

• Draft PR. Surgical generic multi-device persistence/UI slice of feat(app): add Meta Wearables integration and supporting fork updates #9084.
• Low overlap with feat(desktop): microphone picker with Ray-Ban Meta glasses support #9181; this branch does not touch app/lib/pages/home/page.dart.

[Git-on-my-level]

Thanks for pulling this into a much smaller, focused slice. Preserving multiple saved devices while keeping the active btDevice fallback is directionally useful, and the added provider/preferences regression tests cover the core dedupe + live-scan replacement behavior.

A couple of things I’d want checked before this moves out of draft / before maintainer merge review:

• The UI now counts saved offline devices in the same devicesFoundNearby(...) text and renders them in the scan list. Please verify the intended UX here: an offline saved device may not actually be nearby/advertising, and tapping it should have a clear failure/retry path rather than looking like a live nearby device.
• Please make sure the targeted Flutter test and analyzer results are available on the final, non-draft PR head. I couldn’t rely on CI here because this draft currently has no status check summary.

I’m not formally approving while this is draft and checks are unavailable, but this looks like a coherent and reviewable app-side improvement rather than the broad mixed scope from the earlier branch.

[moni11811]

Addressed draft review in 247950c.

Changes:

• Nearby count now uses live scan devices only, not saved offline devices.
• Saved offline devices still render, but show Offline instead of looking nearby.
• Tapping an offline saved device now stops before connection and shows an Offline snackbar with Retry action.
• Added provider regression for nearby count + online/offline state.

Local checks:

• flutter test test/providers/onboarding_provider_multi_device_test.dart
• dart analyze lib/backend/preferences.dart lib/providers/onboarding_provider.dart lib/pages/onboarding/find_device/found_devices.dart test/providers/onboarding_provider_multi_device_test.dart

[Git-on-my-level]

Thanks for this clean, well-scoped slice — preserving multiple paired devices while keeping the legacy single-device fallback is the right architectural direction, and the migration path (empty list falls back to btDevice) is well thought through.

A few observations for you and the maintainer team:

1. UX product question (for human maintainer): Offline saved devices now render in the Find Devices scan list with an "Offline" badge and tap-to-retry snackbar. Please confirm with the product team that showing offline devices in the onboarding/connect flow is the intended experience — vs. only surfacing them in a "saved devices" or device-management screen. The tap-block with retry is a reasonable failure path either way.

2. btDeviceRemove is added to SharedPreferencesUtil but I don't see it called anywhere in this PR. If it's intended for a follow-up device-management screen, that's fine — just flagging it as currently unused.

3. The getBool(prefKey) change on firmware_warning_acknowledged (removing ?? false) is a harmless drive-by since the getter already defaults to false, but it's unrelated to multi-device persistence. Consider reverting it to keep the diff focused.

4. The _didNotMakeItTimer nullable conversion (late Timer → Timer?) and the ?.cancel() calls are a good defensive improvement.

The unit tests covering upsert dedupe, visibleDeviceList merge with live-scan replacement, and nearby-count-vs-saved-device semantics are solid. Once this moves out of draft with CI passing, it should be a smooth human review.

Not formally approving while this is draft and no CI checks are available, but this looks like a coherent and reviewable app-side improvement.