PM-38363: Add a loading ViewState to the PlanScreen

[david-livefront]

🎟️ Tracking

PM-38363

📔 Objective

This PR refactors the PlanViewModel and PlanScreen to have a top level loading and error state for the initial state.

📸 Screenshots

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: APPROVE

This PR refactors PlanViewModel/PlanScreen to hoist loading and error handling into top-level ViewState variants (Loading, Error, and a new Content grouping) instead of overlay dialogs, and consolidates the four state-source flows into a single merge. Tests were updated comprehensively to match the new state model, including the new showsPremiumView/isSelfHosted fields. The refactor is clean and the screen still exposes a top-app-bar back affordance, so removing the error dialogs' "Close" button does not create a dead end.

Code Review Details

• ❓ : Merged-flow gate (first { ... is Content }) blocks special-circumstance / status updates while the screen is in the Error state until a retry succeeds — confirm this is intended for the error path.
  • app/src/main/kotlin/com/x8bit/bitwarden/ui/platform/feature/premium/plan/PlanViewModel.kt:138

Note: handleClosePricingErrorClick / PlanAction.ClosePricingErrorClick appear to no longer have a UI entry point now that the pricing error is a full-screen Error state rather than a dialog with a Close button. Minor dead-code cleanup candidate, not blocking.

[claude]

❓ QUESTION: This gate suspends the merged collector until the view state reaches Content. In the Error state (e.g. a premium user whose getSubscription() call failed), Content is never reached until the user taps "Try again" and it succeeds, so emissions from specialCircumstanceStateFlow / subscriptionStatusStateFlow are held the entire time the error is on screen.

Details

The updated PlanViewModelTest (around line 170) now seeds subscriptionResult = SUBSCRIPTION_SUCCESS_ACTIVE with the comment "The premium subscription must resolve so the screen reaches a Content state and the special-circumstance flow is processed" — confirming special circumstances are not processed until Content.

Concretely: if a StripePortal / PremiumCheckout special circumstance arrives while the screen is sitting in ViewState.Error, it won't be handled (and its specialCircumstance = null clear won't run) until a retry succeeds. Previously these four flows were collected independently, so they were processed regardless of view state.

Was gating these flows during Error (not just initial Loading) intentional, and is the "blocked until successful retry" behavior acceptable for the special-circumstance path? If so, it may be worth a test covering a special circumstance arriving during Error.