PR #136 needs rebase + product decision: AppAlertProvider vs. theme-pass

[TaprootFreak]

Tracking PR #136 (fix: unified in-app alerts + tax-report userAddress + legal in-app webview) which has been stalled since 2026-05-14.

Current state

• 60 commits behind develop (last update 2026-05-14)
• mergeable=false / mergeStateStatus=DIRTY (conflicts)
• iOS Simulator + iOS Visual Regression + Android Emulator E2E: ❌ FAILURE (pre-ci: stabilise Maestro Android run + raise iOS/Android timeouts #157 infra)
• Scope: +465/-118 LOC / 18 files

Open product question

Since #136 was opened, PR #156 (feat(ux): dark mode + theme pass + Pay/Wallets/Settings polish) has landed on develop. #156 already restyles a large chunk of the surfaces that #136's AppAlertProvider was meant to harmonise:

• Are the DFX-styled in-app alerts in fix: tax-report userAddress + legal-docs in-app webview (scoped from alert/tax/legal) #136 still wanted on top of feat(ux): dark mode + theme pass + Pay/Wallets/Settings polish #156's theme pass, or does the theme pass already cover the UX gap?
• The tax-report userAddress and legal in-app webview parts of fix: tax-report userAddress + legal-docs in-app webview (scoped from alert/tax/legal) #136 may stand alone even if the alert refactor is dropped — should those be split out?

Why not autopilot-rebasable

The 18 files touched include several that #156 substantially rewrote (Settings, tax-report screen, legal handling). Resolving the conflicts requires the author to decide which side wins per chunk.

Asks

• Decide: is the AppAlertProvider refactor still desired after feat(ux): dark mode + theme pass + Pay/Wallets/Settings polish #156's theme pass?
• If yes: rebase onto current develop, resolve conflicts.
• Consider splitting tax-report userAddress + legal webview into a separate, conflict-free PR if the alert refactor is being parked.

PR link: #136