fix(rider-app): wire per-driver-fare fallback to also cover stale/missing key case

[variablefate]

Decision (2026-05-05)

Keep per-driver fare for Android. It's a premium UX iOS doesn't have — "this driver costs $11.20 because they're 2 miles away, that one costs $14.50 because they're 6 miles away." Don't drop it.

Add fallback for the cases where driver location isn't available — driver doesn't share location, OR rider doesn't have the key to decrypt it. In those cases, fall back to the rider-route-only fare (pickup→dropoff × per-mile + base). This is the iOS model; on Android it becomes the fallback when location-based pricing is unavailable.

What's already there

The fallback exists. RiderViewModel.kt:1758-1762:

```kotlin
val fareCalc: FareCalc = if (driverLocation != null) {
calculateRoadflareFare(pickup, driverLocation, rideRoute)
} else {
FareCalc(state.fareEstimate ?: return, state.fareEstimateUsd)
}
```

And calculateFare(route) at L4282 is exactly the iOS-style model: `distanceMiles * farePerMile + minimumFare floor`. So state.fareEstimate already holds the iOS-style rider-route fare — Android just upgrades it to per-driver pricing when location is available.

The same if (driverLocation != null) pattern repeats in sendRoadflareOfferWithAlternatePayment (~L1850) and sendRoadflareToAll (~L1945). All three RoadFlare offer entry points already have the fallback.

What's actually missing

Today the fallback only fires when the CALLER passes driverLocation = null — which happens when the driver isn't sharing location (Kind 30014 absent or expired). It does NOT fire when the driver IS sharing location but the rider can't decrypt it (stale key or missing key). In that case today the rider sees the driver as offline entirely and never reaches the offer flow.

The actual work for this issue:

• When the rider has a stale-or-missing RoadFlare key for a driver who is broadcasting Kind 30014, surface that driver in the rider's UI as available (per refactor(roadflare): decouple ride-on-demand from key state + actually-filter mute #82's LOCATION_STALE state) and pass driverLocation = null when calling sendRoadflareOffer.
• Confirm the fallback path produces a sensible UI quote (we want the rider to see the iOS-style fare, not a blank/unknown).
• Add a small inline UI hint when the fallback fare is shown — e.g., "estimated (driver location unavailable)" — so the rider isn't surprised if the actual ride length differs from the per-driver fare they would have seen with a fresh key.
• Pin behavior with a regression test: a stale-key driver in the offer flow produces driverLocation = null → fallback fare is used → offer carries state.fareEstimate and matching state.fareEstimateUsd on the wire.

Relationship to #82

Mostly unblocked. The fare fallback already exists and matches the iOS model, so #82's stale-key offer flow can use it directly. The wiring change above is small enough to fold into #82 if convenient, OR ship as a tiny separate PR before #82.

Out of scope

• Changing calculateRoadflareFare's formula. It's the per-driver premium fare; keep it as is.
• Changing iOS or roadflare-rider behavior. They use the rider-route model unconditionally — that's their canonical path and matches Android's fallback exactly.

[variablefate]

Stance: confirmed — Android rider-app DOES use driver location for per-driver fare

User confirms (2026-05-05) that Android rider-app calculates a per-driver fare that includes the driver→pickup leg, not just pickup→dropoff. So the answer to "investigate whether" is already known — yes.

Concrete code path in rider-app/.../RiderViewModel.kt:

• sendRoadflareOffer(driverPubKey, driverLocation) ~L1752 takes the driver location and passes it to calculateRoadflareFare(pickup, driverLocation, rideRoute) at L1759.
• calculateRoadflareFare(...) ~L1486 does routingService.route(originLat = driverLocation.lat, originLon = driverLocation.lon, ...) — driver→pickup leg is part of the fare basis.
• There IS already a fallback branch when driver location is null: FareCalc(state.fareEstimate, state.fareEstimateUsd) (pickup→dropoff only) at L1761. Same pattern repeats in sendRoadflareOfferWithAlternatePayment at L1850-1855 and sendRoadflareToAll at L1945+.

Implication for the work: this isn't a full rewrite. The fallback branch already exists. The migration to align with iOS is essentially "always take the else branch" — drop the per-driver tier and use rider-route-only fare unconditionally. Or split it: keep per-driver fare for the display ("how much this driver will cost you, including the trip to pick you up") but use rider-route fare for the authoritative `fare_fiat_amount` field on Kind 3173.

Reframe of this issue: investigation is no longer needed — change scope from "verify and fix if needed" to "port iOS rider-route-only fare model to Android." Open questions:

1. Do we drop the per-driver fare tier entirely and match iOS exactly? Or keep it as a UI-only "estimated total" while still emitting the rider-route fare on the wire?
2. The latter is more app value but creates a quote/wire mismatch — driver sees one number, rider was shown another. Probably bad UX.
3. Cleanest path: drop per-driver fare tier; show rider-route fare in offer UI; emit it on Kind 3173. Loses "see exactly what each nearby driver costs" feature.

Blocks #82. Until this is done, the stale-key offer flow proposed in #82 can't work — a rider with a stale key has no driver location, so the current per-driver fare path can't run, the fallback uses pickup→dropoff only, and the offer would carry a different fare than what would have been shown if the key were fresh. Inconsistent UX.

[variablefate]

Updates (2026-05-05)

No UI hint for fallback fare

Earlier scope had "add a small inline UI hint when the fallback fare is shown — e.g., 'estimated (driver location unavailable)'". Pulling it. iOS shows the rider-route fare without any qualifier; Android's fallback should match. The user shouldn't need to think about whether they're seeing the per-driver or rider-route number — both are honest fares.

Schema work eliminated (cross-ref)

Per the comment on #82: `RoadflareLocationEvent.create()` already emits `status` as a public tag. Stale-key followers can read it via `getStatus(event)` without decryption. No protocol changes needed.

Updated scope (smaller than before)

• Rider-side: when a Kind 30014 from a followed driver fails to decrypt (stale/missing key), still surface the driver as available using the public `status` tag. Today the rider treats decryption failure as "driver offline."
• Pass `driverLocation = null` to all three `sendRoadflareOffer*` entry points when the driver's location can't be decrypted. Existing fallback at `RiderViewModel.kt:1761` produces the iOS-style fare from `state.fareEstimate`.
• No UI hint, no special state. Driver appears available; offer carries the rider-route fare; user experience is indistinguishable from iOS.
• Regression test: stale-key driver in offer flow → fallback fare on the wire matches what iOS would send for the same pickup→dropoff route.

This issue can be folded into #82's PR or shipped first as a small standalone change.

[variablefate]

Closed by #85 (merged as adc2400) — the rider-app's per-driver-fare fallback now activates correctly when the rider's RoadFlare key is stale/missing. The user-visible flow per the issue's acceptance criteria:

• Stale-key driver appears as available in the driver list (via the new cachedPresence channel).
• Tapping the driver → sendRoadflareOffer(pubkey, null) → existing fallback at RiderViewModel.kt:1761 produces the iOS-style rider-route fare from state.fareEstimate.
• Kind 3188 stale-signal piggyback fires alongside the offer for inline key recovery.
• No UI hint, no special state — driver appears identically to a fresh-key driver.

The roadflare-rider equivalent (DriverQuoteCoordinator, DriverNetworkTab, DriverSelectionScreen, RideTab) is the remaining "ridestr-side mirror" still to do per the "one PR per app" plan — that scope is its own follow-up and not part of this issue.