Form validation, Bloc, and create/edit submission

Use a Cubit rather than a full Bloc for this form — the event model adds no value over direct method calls for a simple CRUD form. Define a sealed `ActivityTypeFormState` with variants: `ActivityTypeFormInitial`, `ActivityTypeFormValidating`, `ActivityTypeFormSubmitting`, `ActivityTypeFormSuccess(ActivityType result)`, `ActivityTypeFormError(String message)`. Perform field-level validation eagerly on every `onChange` event after the first submit attempt (dirty-field tracking pattern) to give immediate feedback. Determine create vs.

edit mode by checking whether an `initialActivityType` parameter was passed to the Cubit constructor — this avoids conditional logic scattered across the widget. Use `context.read().submit()` from the button `onPressed`; the Cubit guards against duplicate calls by checking if the current state is `ActivityTypeFormSubmitting`. Pop the route with `Navigator.of(context).pop(state.result)` inside a `BlocListener` on `ActivityTypeFormSuccess` — never pop from inside the Cubit itself.

Write unit tests for ActivityTypeFormCubit covering all validation branches (empty name, boundary duration values 4/5/480/481, missing category). Test state transitions: initial → validating → submitting → success and initial → validating → submitting → error. Mock ActivityTypeService with both success and failure responses. Write widget tests verifying: submit button is disabled during loading state; snackbar appears on error; navigator.pop is called with the correct entity on success.

Use bloc_test package for cubit testing. Target 100% branch coverage on validation logic.