What changed

Users whose profile wasn't linked to a specific paired Bluetooth device (common after upgrading from older versions where device selection was optional) previously saw an empty settings screen with no way to figure out what was wrong — the ANC/AAP options wouldn't appear and there was no Connect button either.

The overview card now shows a warning icon in place of the usual settings icon when a profile has no paired device selected. Tapping it jumps straight to the profile editor so the user can pick their AirPods from the paired-devices list.

Technical Context

• Root cause: AppleDeviceProfile.address is nullable, and AapAutoConnect.initialConnect() filters profiles by it.address in connectedAddresses — a null address silently never matches, so AAP never tries to connect. Three unrelated UI paths were also gated on device.address != null (overview card's settings icon at SinglePodsCard.kt:141 / DualPodsCard.kt:142, the DeviceSettings nav route in OverviewViewModel.goToDeviceSettings, and the NotConnectedCard at DeviceSettingsScreen.kt:245), so the broken state had zero visible affordance for the user to diagnose or fix it. The reporter in Help wanted: Using L2CAP connection to read from and write settings to AirPods #215 had to delete and recreate the profile because that was the only UI lever not hidden by the null-address gate.
• Affected cohorts: v2.x upgraders whose legacy oldMainDeviceAddress was empty at the single→multi migration (migration copies null and permanently flips singleToMultiMigrationDone), and v3.x/v4.x users who saved a profile without picking a bonded device — nothing required it before AAP landed in v5.0.0-beta0.
• Alternative considered and rejected: auto-backfilling the address by matching connected classic BT devices to null-address profiles by pod model. In environments with multiple bonded AirPods of the same model the unique-model heuristic has too many false-positive modes, so explicit user action is safer.
• The warning is gated on device.profileId != null && device.address == null so it never fires for anonymous BLE devices (which have their own existing UX).

Related to #215