Mobile client never registers for push; live-WebSocket-only causes silent gaps on cellular

[cjpatten]

Describe the bug

The server side of NIP-PL push leases is fully built and shipped (buzz-push-gateway, APNs delivery, kind:30350 lease protocol — see #1770), but the Flutter mobile client never uses any of it. Mobile relies entirely on a live WebSocket for updates, so backgrounding + cellular tower handoffs (which silently kill sockets without a clean close) produce repeated gaps in message/badge delivery, not a one-time reconnect blip.

Confirmed by reading mobile/ on main:

• mobile/ios/Runner/AppDelegate.swift calls UNUserNotificationCenter.current().requestAuthorization(options: [.badge]) only — it never calls UIApplication.registerForRemoteNotifications(), never implements didRegisterForRemoteNotifications/didFailToRegisterForRemoteNotifications, and has no APNs device-token handling at all. The .badge request only supports the local app-icon badge, not push.
• No occurrence of push_gateway, apns, kind: 30350, or push-lease creation anywhere under mobile/lib.
• No Firebase/FCM dependency in mobile/pubspec.yaml — Android has no push path whatsoever.
• All live updates go through mobile/lib/shared/relay/relay_socket.dart, a plain WebSocket client with no wake/reconnect assist from the platform push channel.

Worth noting the gap isn't only client-side: crates/buzz-push-gateway/src implements apns.rs but has no fcm.rs, so even the server gateway can't deliver Android pushes yet, independent of the mobile client issue.

Steps to reproduce

1. Open the Buzz mobile app on iOS or Android, background it, and move to cellular data (leaving home Wi-Fi triggers this reliably).
2. Have another user send a message or reply in a channel you're a member of.
3. Observe: notification badge / bold-unread-count updates are inconsistent — sometimes delayed well past the app's normal WebSocket-reconnect window, sometimes missing until the app is foregrounded and reconnects manually.

Expected behavior
Given the NIP-PL / buzz-push-gateway infrastructure already exists server-side, the mobile client should create and maintain a push lease (kind:30350) per installation, register for platform push (APNs on iOS via registerForRemoteNotifications, FCM on Android once the gateway supports it), and use the resulting wake signal to reconnect promptly instead of relying solely on a live socket surviving backgrounding and cell handoffs.

Version and platform

• Buzz version: main (as of 2026-08-04)
• OS: iOS and Android, cellular networks specifically

Logs / additional context
No client-side logs to attach — this is a structural/architectural gap found via code review, not a single reproducible stack trace. Relevant server-side context: docs/push-gateway-deployment.md, docs/nips/NIP-PL.md, CHANGELOG feat(push): add public APNs gateway (#1770).