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

**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)`.

Read mobile/ios/Runner/AppDelegate.swift, mobile/pubspec.yaml, mobile/lib/shared/relay/relay_socket.dart, and crates/buzz-push-gateway/src/apns.rs, then compare them with docs/push-gateway-deployment.md and docs/nips/NIP-PL.md. Done means platform push registration, per-installation kind:30350 lease handling, and prompt reconnect behavior work across iOS and Android, including the server-side Android path.

Written by the indexing model from the issue text.