Mobile: register the device push token after login (#87)

[rghvgrv]

Closes the client-side wiring for #87 — everything that does not require a real FCM token.

What changed

POST /api/v1/devices shipped in #63 and has never been called. DevicesController was the only backend controller without a Refit interface on the mobile side, so RenewalAlertBackgroundService looks up device tokens on every due subscription and finds zero, every time.

• IDevicesApi — [Post("/api/v1/devices")], registered in MauiProgram through AuthDelegatingHandler like every other authenticated client. The response body is the stored device_tokens row and is of no use to the client, so the method returns bare Task and a non-success status surfaces as the ApiException the caller already swallows.
• RegisterDeviceTokenRequest in Api/Dtos/ mirroring the backend's contract by convention (no shared DTO project, per the existing decision).
• IPushTokenProvider — the platform seam, alongside IConnectivityService and ITokenStore. Exposes Platform ("Android" / "iOS", exactly what RegisterDeviceTokenRequestValidator accepts) and GetTokenAsync().
• LoginViewModel posts the token after a successful login.

Why registration is best-effort

A user who cannot receive notifications must still be able to use the app, so:

• it runs after LoginSucceeded is raised, so navigation is never delayed by a slow or hanging network call;
• a null or blank token — the permission-refused path — posts nothing;
• every exception, from either the provider or the API call, is swallowed.

The backend upsert on (user_id, token) makes repeat calls harmless, which is what lets this be fire-and-forget without a dedup guard on the client.

The provider implementation is a placeholder

UnavailablePushTokenProvider always returns null. The real Firebase-backed one needs the messaging SDK from #86, which is blocked at its own step 1: a human must provision the Firebase project and supply google-services.json / GoogleService-Info.plist, and decide whether those files are committed given the detect-secrets hard stop.

I deliberately did not add a Firebase binding package here. It cannot be built or run without those config files, so adding it would mean committing an unverifiable vendor dependency — the package choice belongs in #86 alongside the config it needs.

The null path is the same one a permission refusal takes, so the flow around the seam is fully exercised today. When #86 lands, the only change here is the one DI line in MauiProgram.

Tests

tests/SubVora.Mobile.Tests/LoginViewModelTests.cs, with new hand-written FakeDevicesApi and FakePushTokenProvider matching the existing fake style:

• a successful login registers the token with the correct platform string;
• null / empty / whitespace tokens register nothing and the login still succeeds;
• a throwing IDevicesApi does not fail the login;
• a throwing IPushTokenProvider does not fail the login.

dotnet test tests/SubVora.Mobile.Tests/SubVora.Mobile.Tests.csproj -c Release → 78 passed, 0 failed.

The Android TFM was not built locally (no Android SDK on this machine); CI does not build it either — the mobile job runs the Windows TFM on windows-latest.

Still open

#87 stays open. Two of its three acceptance criteria need a real token on a real device:

• A denied permission or a failed registration call never blocks or fails the login
• A successful login registers the device's FCM token, and logging in again updates last_seen_at rather than duplicating the row
• A due subscription for a user with a registered device results in a delivered push notification

Both unblock the moment #86 does.