fix(deeplinks): route v2 tab deeplinks without a modal sheet

[bmc08gt]

Audit of every deeplink entry point under FeatureFlag.NewUi, plus fixes for what it turned up. Eight findings; four are addressed here, and the rest are noted at the bottom.

v2 tab deeplinks opened a modal sheet

resolveRoutes wrapped every AppRoute.Sheets entry in a modal Main.Sheet unconditionally. Under NewUi the tab homes — Sheets.Wallet, Sheets.Tips, Sheets.Menu — are top-level tab destinations, not modals, so every navigational deeplink opened a sheet that hid the hoisted nav bar and left Menu/Tips with no close affordance.

resolveRoutes and navigateAll now take isNewUi. In v2 a Sheets route that maps to a nav bar tab stays flat on the root backstack and the remaining routes resolve on top of it; a list leading with a tab home is applied as a tab switch (PopUpTo.ClearAll), matching AppNavigationBar. Genuine modals such as Sheets.ActivityHistory still wrap in both shells, including when they follow a tab home. A tab switch arriving while a sheet is open goes through pendingSheetDismiss so the sheet animates out rather than being cleared from under itself.

resolveBackStack is new: it lets MainRoot's idempotence guard predict the stack navigateAll actually produces. Without it, v2 computed an extra tab entry and re-navigated on every auth/flags re-emission.

Threaded through all four deeplink entry points — cold start (MainRoot), warm start (App), QR scan (Scanner) and the post-tip chat handoff (TipCardDecorator). Scanner's Navigatable branch also gains the TipChat case it was missing, so a scanned tip DM code lands where the /tip/chat/{id} deeplink does instead of silently doing nothing.

/verify was a crash, not a no-op

EmailDeeplinkOrigin.deserialize indexed split results blindly and let a bad Fiat payload throw; handleEmailVerification threw on malformed client_data JSON or base64. Both dispatch call sites are unguarded — composition in MainRoot, a LaunchedEffect in App — and every handled host is autoVerify, so a crafted link from any web page took the app down.

classify is now a guarded wrapper that traces and degrades to "no deeplink", and each parse step fails soft. Also drops the unreachable "menu" origin branch, which serialize never emits.

/verify decoded its query parameters twice

Uri.getQueryParameter already percent-decodes, so the extra urlDecode on email and client_data ran a second, form-semantics decode over already-decoded text. Three ways that bites:

• a plus-tagged address arrives corrupted — email=user%2Btag%40x.com decodes to user+tag@x.com, then URLDecoder turns the + into a space and the code is verified against user tag@x.com, an address the user never entered;
• client_data.origin is standard base64, whose alphabet includes +, so the same substitution breaks the base64 and the origin silently resolves to null — dropping the routing destination;
• URLDecoder throws on an incomplete escape, so an address containing a literal % (legal in a local part) arrives as 100%off@x.com and takes the whole link down.

Both calls dropped, with regression coverage for each case. A further test pins the contract: getQueryParameter is a form decoder, which is the exact inverse of the client-side encoder that builds these links, so decoding a second time is never correct here.

Two manifest/router disagreements

• jump.flipcash.com was autoVerify'd with no routing at all, so every jump link dead-ended on the home screen. It's a redirector — the real URL is percent-encoded in the fragment as #source=<url> — so it now unwraps and classifies the inner link, mirroring iOS DeepLinkController. Unwraps once rather than recursing, decodes percent escapes only (a + in a URL is a literal plus), and takes everything after source= so an unencoded query string in the wrapped URL survives.
• /chat/.* was claimed and autoVerify'd, but AppRouter deliberately doesn't classify chat links — the direct-send entry point they opened was removed. Capturing a URL to do nothing with it is worse than not capturing it, so the filter is gone and those links open in the browser again. The AppRouter comment and the manifest now cross-reference each other so the two can't drift apart.

Testing

• AppRouterTest — 50 tests, ResolveRoutesTest — 18, NavigateToTest — 16. All green.
• Verified on device with a before/after build of the same link in the same session, read off the TraceType.Navigation logs:
  • before: Navigating to Sheet(initialRoute=Wallet, innerRoutes=[Info(mint=EPjF…)]) from Wallet with NavOptions(popUpTo=None)
  • after: Navigating to Wallet from Wallet with NavOptions(popUpTo=ClearAll) then Navigating to Info(mint=EPjF…) from Wallet
• Back-press from the token page lands on the real Wallet tab with the nav bar, where it previously landed on a modal sheet.
• A jump-wrapped token link unwraps and renders the same token page.
• cmd package query-activities confirms /chat/abc123 now resolves to Chrome only, while /token/abc123 still resolves to MainActivity.

Not addressed here

• Logged-out deeplinks are dropped rather than deferred. A /token/... tap by a signed-out user gets AppRoute.OnboardingFlow() and the target is lost; only Login links carry their payload through onboarding.
• /chat/{id} iOS↔Android parity. iOS routes /chat/{id} and /chat/{id}/send; Android intentionally does not.