Use an independent application state manager

This scenario uses one ordinary immutable application state and a broadcast Stream. No UseCase Forge type appears in the feature implementation.

1. Expose state and changes

The manager owns current ApplicationState, publishes change signals, and provides named operations such as toggleTheme() or selectLanguage().

2. Build the ModelBinding

Composition reads the current application state and captures only the operations this screen needs. The binding observes the manager Stream.

3. Provide the binding through context

MvpModelProvider<ApplicationModel>.value(
  binding: applicationBinding,
  child: const ApplicationScreen(),
)

A descendant MvpView<ApplicationModel, ...> can omit its direct model argument. Exact Model type determines lookup; interfaces are not registered automatically.

4. Use presentation context safely

FlutterPresenter.buildViewState(context) can read Theme, locale, and text direction while deriving ViewState. It must not cache that context. Actions receive explicit parameters or invoke allowed Model operations.

5. Preserve ownership

The surrounding widget creates and closes the manager. MvpModelProvider.value exposes the binding but does not acquire ownership of the manager. MvpView creates and closes Presenter.

This example demonstrates the intended universality: Ark MVP defines the presentation boundary, while the application chooses its business-state mechanism.