Fix Omi Dev startup and recover silent Pendant connections

[Git-on-my-level]

What changed and why

Fix the Omi Dev iOS startup crash, then make Pendant connection state and recovery truthful across three failure modes observed on a physical iPhone:

• A saved Pendant was labeled Offline whenever it was absent from the latest advertisement scan, even though iOS could still reconnect it by its saved peripheral identifier. The displayed Retry action had an empty callback. Retry now runs the real forced-connection flow.
• A Limitless Pendant could remain GATT-connected but silent. Initial subscriptions now get the same single bounded CCCD retry as reconnects. Limitless reconnects repeat time sync before enabling realtime mode, then a bounded health watchdog distinguishes no RX packets from RX-without-audio, probes device status, and retries stream activation once without looping.
• CoreBluetooth authentication failures could arrive from notification-state or value callbacks, not only protected writes. Those paths now consistently surface pairing_lost and tear down the unusable link.

The Dart device service still rejects partially initialized connections, and onboarding persists success only after device-specific initialization completes. Omi Dev uses compatible Awesome Notifications packages and the correct dev Profile/Release CocoaPods configurations and bundle identifiers.

The iOS dev configuration deliberately preserves both contributor paths: Debug-dev keeps watch signing disabled so the established account-free simulator workflow continues to work, while Profile-dev and Release-dev sign the embedded watch app so physical-device bundles are installable. A static contract now locks that split, the single-suffix dev widget identifier, and the dev Profile/Release identity. CocoaPods remains the sole owner of framework search paths.

Product invariants affected

none

How it was verified

• On an iPhone 15 Pro Max running iOS 26.6, an isolated native probe connected to the Limitless Pendant, discovered its services, enabled RX notifications, and measured about -46 dBm RSSI. The time-sync and stream-enable writes both returned CoreBluetooth Authentication is insufficient; the probe observed zero stream-data/audio packets. This isolated that no-transcript incident to the BLE bond/control-write boundary, before websocket or transcription processing.
• Source tracing of the production Offline / Retry UI found the scan-only classification and literal no-op callback. Regression coverage now proves Retry invokes the connection callback, while existing provider coverage proves saved non-advertising devices remain visible and are classified separately from scan results.
• A paired iPhone 17 Pro / Apple Watch simulator Debug-dev build passed with watch signing disabled. A physical Profile-dev build then passed with watch signing enabled, resolved to com.friend-app-with-wearable.ios12.development, and passed strict code-sign verification.
• No production credentials were copied and the one-off diagnostic probe is not included in this PR.

Tests

• bash test.sh — 1,586 passed, 5 skipped.
• scripts/analyze_ratchet.sh — passed.
• for test_file in ios/test/*_test.rb; do ruby "$test_file" || exit 1; done — 39 runs, 695 assertions, 0 failures.
• Focused Flutter regressions for saved-device Retry, multi-device onboarding, Limitless reconnect/health behavior, and native BLE resubscription — passed.
• flutter build ios --simulator --flavor dev --debug -d <paired-simulator-id> — passed.
• flutter build ios --flavor dev --profile — passed; the resulting device bundle passed codesign --verify --deep --strict.
• make preflight — all 17 selected checks passed.

Factory reset was not required for these software-side fixes and was not performed. The remaining physical acceptance check is to open the installed Omi Dev build while the phone is unlocked, connect the Pendant, and confirm first RX/audio instrumentation followed by live transcripts.

Failure class (fixes)

Failure-Class: none