Decommission public OSRM and add offline-capable Wayfarer routing

[stef-k]

Problem and user impact

WayfarerMobile currently treats the public OSRM demonstration server as a production routing dependency, contacts it directly with user coordinates, logs coordinate-bearing request URLs, and keeps an untrusted five-minute OSRM preference cache. The accumulated contract also contained conflicting provider/persistence authorities and obsolete backend assumptions.

A concrete backend gap was discovered after the Mobile #260 red checkpoint: the existing capability and route endpoints require a server-owned TransportProfileId GUID, while Mobile has only textual hints; the public Segment DTO omits current Segment.TransportProfileId; ad-hoc targets have no Segment identity; and existing response identity is insufficient for the complete stale-publication fence. Bounded Wayfarer issue stef-k/Wayfarer#528 owns only that prerequisite.

Final product outcome

Decommission all direct public-provider routing from Mobile, add the bounded backend discovery prerequisite, then add optional authenticated provider-neutral Wayfarer routing and bounded same-user offline reuse. Saved Trip Segment geometry remains authoritative, Direct guidance remains explicitly selectable and universally available, and routing failure never blocks authentication, synchronization, Trip use, or ordinary offline behavior.

Settled provider and persistence authority

For the stef-k/Wayfarer#505 release:

• Geoapify is the storage-authorized hosted routing path.
• Mobile contacts only the configured authenticated Wayfarer server and never receives provider credentials.
• Wayfarer owns provider/profile/credential resolution, profile discovery, admission, transport, validation, and storage authority.
• Authorized validated Geoapify routes returned through the provider-neutral API may be retained under the bounded same-user offline contract with Geoapify and OpenStreetMap attribution.
• Public OSRM must be removed. Mapbox Directions is absent; Add Mapbox Directions with personal budgets and an offline-retention policy gate Wayfarer#500 is closed as not planned and is not a dependency. Nominatim is not a Mobile routing provider.
• No other provider's durable route storage is inferred or authorized.

Backend capability and bounded gap

Wayfarer already provides:

• no-contact per-profile capability and a provider-neutral route endpoint;
• bounded origin/destination/anchor input with no client-selected provider, native mode, endpoint, or credential;
• existing authentication and user authorization;
• authoritative Geoapify provider/profile/credential resolution;
• shared credit admission, pacing/timeout, route validation, geometry budgets, and post-contact authority revalidation;
• bounded failure outcomes and privacy-safe server ownership;
• validated geometry, metrics, normalized instructions, generated timestamp, stable non-secret identities, match inputs, attribution, and storage mode;
• no server persistence or Trip/Segment mutation for ad-hoc Mobile routes.

That boundary is not complete for Mobile profile selection. stef-k/Wayfarer#528 adds only authenticated provider-neutral profile discovery, one opaque selection/publication authority identity with pre-contact comparison and response echo, and additive current Segment TransportProfileId. It changes no capability meaning, contacts no provider, admits no credit, persists no route, requires no migration, and adds no Mobile code. No additional backend work is implied by this epic beyond #528.

Child issues and strict order

• Remove direct public OSRM routing from Mobile #259 — Remove direct public OSRM routing from Mobile (completed and merged).
• Expose provider-neutral Mobile routing profile discovery Wayfarer#528 — Expose provider-neutral Mobile routing profile discovery (blocking backend prerequisite).
• Add authenticated provider-neutral Wayfarer routing #260 — Add authenticated provider-neutral Wayfarer routing.
• Add bounded offline Wayfarer route persistence and reuse #261 — Add bounded offline Wayfarer route persistence and reuse.

Execute serially:

1. preserve Remove direct public OSRM routing from Mobile #259 as completed and Mobile main synchronized;
2. implement/review/exact-head CI gate/merge Expose provider-neutral Mobile routing profile discovery Wayfarer#528 and synchronize Wayfarer main;
3. resume the preserved Mobile Add authenticated provider-neutral Wayfarer routing #260 red checkpoint, implement/merge Add authenticated provider-neutral Wayfarer routing #260, and synchronize Mobile main;
4. implement/merge Add bounded offline Wayfarer route persistence and reuse #261 and synchronize Mobile main;
5. validate the combined Mobile candidate with the coordinated release under Coordinate the provider migration and backend/mobile routing releases Wayfarer#505.

Each implementation must be independently reviewed, exact-head CI-gated, merged, and synchronized before the next dependent slice begins. No child may restore public OSRM or make ordinary synchronization depend on routing. The preserved #260 checkpoint 4655bb03a4cd512cee5638dae24b8c85ed3e08e7 remains unchanged until the backend prerequisite merges.

Truthful intermediate states

After completed #259, saved Segment geometry and Direct guidance work and no public routing-provider contact exists; hosted routing is absent.

After stef-k/Wayfarer#528, the backend can authoritatively expose eligible profile GUIDs and current Segment selection plus one opaque authority fence, but no Mobile implementation or deployment is implied.

After #260, connected routed guidance may work through authenticated Wayfarer discovery/capability/route; old/provider-disabled backend states remain safe; the final request-generation/current-target/authority publication fence makes only the newest still-authorized target eligible for presentation or later persistence; provider routes, discovered selection, and the shared canonical request identity remain transient and no durable persistence is authorized yet.

After #261, only authorized validated routes survive offline under the local account partition, shared five-decimal canonical coordinate identity, accepted authority/profile provenance, and global 200-row deterministic LRU policy.

Final navigation authority

For saved Trip Segments:

1. valid Trip-owned saved Segment geometry;
2. valid matching retained Wayfarer route when applicable;
3. fresh authenticated Wayfarer route using current discovered authority when connected, authorized, and requested;
4. Direct guidance.

For ad-hoc Place/member/map targets:

1. valid matching retained Wayfarer route when applicable;
2. fresh authenticated Wayfarer route using current discovered selection;
3. Direct guidance.

Direct remains explicitly selectable. Never blend partial provider geometry with Direct geometry or fabricate road-aware connections.

Cross-child identity invariants

Keep four concepts distinct across the children:

• current public Segment TransportProfileId is a preferred fresh-selection hint only while present in current discovery;
• retained RouteTransportProfileId is provenance for stored geometry, not current selection authority;
• textual Mobile mode values are provider-neutral preference hints and never manufacture a GUID;
• ad-hoc targets select only from discovered eligible identities because they have no Segment authority.

#260 owns the canonical transient request identity, including discovery AuthorityIdentity, authoritative profile GUID, session/account/server, ordered five-decimal coordinates/anchors, target association, generation, and explicit Direct state. The final publication fence must reject drift before publication even when cancellation or backend pre-contact rejection is unavailable. #261 must reuse that exact owner and representation rather than create another coordinate or authority identity.

Compatibility invariants

Existing released Mobile with the new backend retains authentication/session continuity, Location/Timeline upload and synchronization, cursor continuity, Trip/Place/Segment deserialization, saved Segment geometry, Direct guidance, and tolerant additive DTO handling. It safely ignores the additive discovery endpoint, current Segment profile, and routing authority response fields.

New Mobile with an old/provider-disabled backend keeps authentication and synchronization, Trip download/use, saved geometry, and Direct guidance. Missing discovery/capability, 404, disabled/unconfigured provider, no eligible profile, routing-specific authorization failure, or route failure remains routing-local; there is no third-party fallback. Discovery must succeed and return an eligible identity before new Mobile makes capability or route contact.

New Mobile with new backend receives authenticated provider-neutral discovery/routing without credentials, validates authority and results, persists only authorized routes with attribution after #261, bounds failures, and leaves ordinary synchronization unaffected.

Privacy, security, and data preservation

Mobile never contacts a routing provider or logs coordinate-bearing routing URLs, coordinate arrays, member identity, credentials, tokens, raw provider responses, protected provider configuration, or component generations. Wayfarer routing failures must not invalidate the global session. Discovery contacts no provider and consumes/reserves no routing credit.

Keep Trip-owned Segment geometry, retained Wayfarer routes, transient navigation/profile selection, OSM live tiles, and credentials/provider configuration as distinct owners. Routing cleanup must not delete or reset Location/Timeline data or cursors, queues, Trips/Places/Segments/waypoints, saved Segment geometry, unrelated settings, credentials/session state, or OSM tile data. Failed refresh, outage, key/provider/profile change, stale discovery, or lack of connectivity must not erase the last valid retained route unless a specific authoritative invalidation contract applies.

Cross-child evidence

Use controlled transports only; never contact public or commercial providers in tests. Prove each responsibility at its lowest stable seam with production behavior dominant:

• absence of direct third-party Mobile contact and privacy-leaking URL logs;
• saved geometry/ordered subedges and Direct behavior after removal;
• backend authenticated no-contact discovery, eligible profile filtering/order, opaque authority stability/change, stale-identity pre-contact rejection, response echo, and current-versus-retained Segment projection under Expose provider-neutral Mobile routing profile discovery Wayfarer#528;
• Mobile zero/one/multiple/no-textual-match discovery selection and strict separation of current, retained, textual, and ad-hoc identities;
• authenticated discovery/capability/route success plus representative bounded routing-local failures against old/disabled/new backend states;
• strict response validation, attribution, and no provider credential exposure;
• Add authenticated provider-neutral Wayfarer routing #260 request-generation/current-target/authority stale-publication fencing at the shared transient identity seam;
• production SQLite round-trip, local account-partition isolation, shared five-decimal coordinate identity, atomic replacement, global 200-row LRU retention, failed-refresh preservation, bounded cleanup, and isolation from Trip/Timeline/tile data under Add bounded offline Wayfarer route persistence and reuse #261;
• one representative combined navigation flow and Android Release compilation for each child whose MAUI/DI/database seam requires it;
• exact-head GitHub Actions test for every implementation PR, followed by final joint candidate evidence under #505.

Do not manufacture exhaustive endpoint/provider/connectivity/device matrices or test harnesses comparable in size to the product work.

Exclusions

• backend routing work beyond the bounded Expose provider-neutral Mobile routing profile discovery Wayfarer#528 prerequisite;
• reopening provider selection or Add Mapbox Directions with personal budgets and an offline-retention policy gate Wayfarer#500;
• Mapbox Directions, Nominatim routing, public OSRM, provider SDKs/credentials on Mobile, or direct provider fallback;
• generic routing/storage frameworks, speculative providers, background prefetch, route packages;
• tile-cache changes or broad SSE, Timeline, Trip, authentication, database, or UI refactors;
• deployment, production migration, provider configuration, artifact publication, or release authorization.

Relationship to Wayfarer #505

This epic owns the Mobile implementation decomposition and combined pre-release Mobile routing candidate. stef-k/Wayfarer#505 remains the authoritative coordinated-release contract and owns the backend candidate including #528, frozen candidates, joint compatibility evidence, deployment, provider configuration, physical-device acceptance, publication, rollback, and final release go/no-go.

Completion criteria

Close #253 only when completed #259 remains preserved, stef-k/Wayfarer#528 is independently reviewed/exact-head CI-gated/merged with Wayfarer main synchronized, #260 and then #261 are independently reviewed/exact-head CI-gated/merged in order with Mobile main synchronized, documentation/changelog acceptance is complete, and the combined Mobile routing candidate passes required pre-release integration evidence. Production deployment and publication are not required to close #253 and remain owned by stef-k/Wayfarer#505.