fix(ios): scan for both Base and Alt BLE service UUIDs

[Flo5k5]

The firmware publishes two distinct 128-bit service UUIDs depending on
which mode is active:

• e2e5e5e0-1234-5678-1234-56789abcdef0 (Base)
  Used by startBleServer() for runtime control (motion, avatar, RGB...)

• e2e5e5ff-1234-5678-1234-56789abcdef0 (Alt)
  Used by startAppConfigServer() for Wi-Fi provisioning / pairing

iOS scanForPeripherals(withServices:) only returns devices whose adv
payload contains the requested UUIDs, so scanning only the Base UUID
means the app is blind to the device whenever it is in Setup/pairing
mode - which is exactly when the app needs to connect to it.

Add both UUIDs to targetServiceUUIDs so the scan succeeds in either
mode. Observed behaviour before: BLE scan silently matched nothing,
user stays on "device offline" screen forever after scanning the QR.

[Flo5k5]

Hi 👋 — closing this PR as fixed-by-replacement. The upstream merged commit e8b9973 ("prepare v1.1.4 release with native bridge and stability cleanups" #38) completely replaced the native SwiftUI iOS app with a Flutter app. The Swift file(s) this PR patches (app/StackChan/*.swift) have been deleted upstream and replaced by app/lib/*.dart + app/ios/Runner/*.swift (Flutter native bridge). The patch is no longer applicable as-is.

I've preserved the Swift-based patches on a dedicated branch legacy/swift-ios on my fork, in case the underlying fix logic can be ported to the Flutter codebase later (BLE scan trigger, dual UUID scan, Wi-Fi push on Confirm, online/offline bool swap).

Happy to re-open or re-submit against the Flutter codebase if useful. Thanks for the review on the merged firmware PRs (#20/#21/#24) 🙏