feat: Migrate staff profile features from Data Connect to V2 REST API

- Removed data_connect package from mobile pubspec.yaml.
- Added documentation for V2 profile migration status and QA findings.
- Implemented new session management with ClientSessionStore and StaffSessionStore.
- Created V2SessionService for handling user sessions via the V2 API.
- Developed use cases for cancelling late worker assignments and submitting worker reviews.
- Added arguments and use cases for payment chart retrieval and profile completion checks.
- Implemented repository interfaces and their implementations for staff main and profile features.
- Ensured proper error handling and validation in use cases.

.claude/agents/mobile-builder.md

@@ -43,10 +43,11 @@ If any of these files are missing or unreadable, notify the user before proceedi
 - Import icon libraries directly — use `UiIcons`
 - Use `Navigator.push` directly — use Modular safe extensions
 - Navigate without home fallback
-- Call DataConnect directly from BLoCs — go through repository
+- Call API directly from BLoCs — go through repository
 - Skip tests for business logic
 
 ### ALWAYS:
+- **Add `CoreModule` import to every feature module that uses `BaseApiService` or any other `CoreModule` binding** (e.g., `FileUploadService`, `DeviceFileUploadService`, `CameraService`). Without this, the DI container throws `UnregisteredInstance` at runtime. Add: `@override List<Module> get imports => <Module>[CoreModule()];`
 - **Use `package:` imports everywhere inside `lib/`** for consistency and robustness. Use relative imports only in `test/` and `bin/` directories. Example: `import 'package:staff_clock_in/src/presentation/bloc/clock_in/clock_in_bloc.dart';` not `import '../bloc/clock_in/clock_in_bloc.dart';`
 - Place reusable utility functions (math, geo, formatting, etc.) in `apps/mobile/packages/core/lib/src/utils/` and export from `core.dart` — never keep them as private methods in feature packages
 - Use feature-first packaging: `domain/`, `data/`, `presentation/`
@@ -72,7 +73,7 @@ If any of these files are missing or unreadable, notify the user before proceedi
 The mobile apps are migrating from Firebase Data Connect (direct DB) to V2 REST API. Follow these rules for ALL new and migrated features:
 
 ### Backend Access
-- **Use `ApiService.get/post/put/delete`** for ALL backend calls — NEVER use Data Connect connectors
+- **Use `ApiService.get/post/put/delete`** for ALL backend calls
 - Import `ApiService` from `package:krow_core/core.dart`
 - Use `V2ApiEndpoints` from `package:krow_core/core.dart` for endpoint URLs
 - V2 API docs are at `docs/BACKEND/API_GUIDES/V2/` — check response shapes before writing code
@@ -87,7 +88,7 @@ The mobile apps are migrating from Firebase Data Connect (direct DB) to V2 REST
 - **RepoImpl lives in the feature package** at `data/repositories/`
 - **Feature-level domain layer is optional** — only add `domain/` when the feature has use cases, validators, or feature-specific interfaces
 - **Simple features** (read-only, no business logic) = just `data/` + `presentation/`
-- Do NOT import from `packages/data_connect/` — it is deprecated
+- Do NOT import from `packages/data_connect/` — deleted
 
 ### Status & Type Enums
 All status/type fields from the V2 API must use Dart enums, NOT raw strings. Parse at the `fromJson` boundary with a safe fallback:
@@ -169,7 +170,7 @@ Follow these steps in order for every feature implementation:
 - Create barrel file exporting the domain public API
 
 ### 4. Data Layer
-- Implement repository classes using `ApiService` with `V2ApiEndpoints` — NOT DataConnectService
+- Implement repository classes using `ApiService` with `V2ApiEndpoints`
 - Parse V2 API JSON responses into domain entities via `Entity.fromJson()`
 - Map errors to domain `Failure` types
 - Create barrel file for data layer
@@ -266,7 +267,7 @@ After completing implementation, prepare a handoff summary including:
 As you work on features, update your agent memory with discoveries about:
 - Existing feature patterns and conventions in the codebase
 - Session store usage patterns and available stores
-- DataConnect query/mutation names and their locations
+- V2 API endpoint patterns and response shapes
 - Design token values and component patterns actually in use
 - Module registration patterns and route conventions
 - Recurring issues found during `melos analyze`