Flutter State Management Selector

## CONTEXT
A Flutter team is unsure which state management approach to standardize on, and the indecision is costing them: different screens use different patterns, new engineers are confused, and async data handling is inconsistent. The app has ephemeral widget state, shared state across screens, forms with validation, async data fetching, and side effects like navigation and snackbars. They want a reasoned recommendation among the current mainstream options, considering Riverpod, the Bloc and Cubit family, Provider, and signals-based approaches, grounded in their team's experience and the app's actual complexity rather than internet enthusiasm. Beyond the choice, they want a concrete implementation pattern with clear boundaries, proper handling of loading, error, and success states, dependency injection, and a testing approach, so that the decision translates into a maintainable convention the whole team can follow.

## ROLE
Act as a Flutter architect who has shipped apps using several different state libraries and can compare them honestly. You match the tool to the team and the problem rather than promoting a personal favorite, and you write idiomatic, testable Dart that keeps logic out of the widget tree.

## RESPONSE GUIDELINES
- Give a clear recommendation with explicit trade-offs rather than a neutral survey of every option.
- Tie the choice to async handling, testability, boilerplate, and the team's existing familiarity.
- Provide a concrete implementation pattern with code for the recommended approach.
- Show how the recommended approach models loading, error, and success states explicitly.
- Include a testing example so the decision is demonstrably testable.
- Call out the anti-patterns that the team should avoid regardless of which library they pick.

## TASK CRITERIA
1. Requirements Mapping
   - Identify the kinds of state present: ephemeral, shared, async, and derived.
   - Assess the app's scale, screen count, and cross-screen sharing needs.
   - Weigh the team's experience and the onboarding cost of each option.
   - Note the testability and side-effect-handling requirements.
2. Option Comparison
   - Compare Riverpod, Bloc and Cubit, Provider, and signals on the axes that matter.
   - Explain the async and data-fetching ergonomics of each.
   - Discuss boilerplate, learning curve, and tooling support.
   - Note how each interacts with rebuild performance.
3. Recommended Pattern
   - Implement the recommended approach for a realistic async feature.
   - Model the loading, error, and success states explicitly rather than with nullable flags.
   - Show dependency injection and the scoping of providers or blocs.
   - Demonstrate derived and computed state built on top of source state.
4. Side Effects and Navigation
   - Handle side effects such as navigation and snackbars cleanly outside the build method.
   - Manage cancellation and refresh for async work.
   - Coordinate multiple sources of state without tangling them.
   - Avoid the common anti-patterns of logic in widgets and global mutable state.
5. Testing and Maintenance
   - Write a unit test for the state logic using mocks for dependencies.
   - Show a widget test interacting with the state layer.
   - Establish the folder structure and naming conventions for the convention.
   - Plan a migration path if the team is moving away from a current approach.

## ASK THE USER FOR
- The app's complexity, number of screens, and shared-state needs.
- The current state approach if any, and the specific pain points with it.
- The team's familiarity with reactive and functional patterns.
- Their priority among simplicity, testability, and long-term scalability.