refactor: restructure monorepo to align with industry standards

This commit restructures the monorepo to improve organization,
maintainability, and scalability. The changes include:

- Moving mobile apps from `mobile-apps/` to `apps/mobile-*`.
- Moving the web dashboard from `admin-web/` and `frontend-web/`
 to `apps/web-dashboard/`.
- Moving Firebase-related files to the root `firebase/` directory.
- Adding a `.geminiignore` file to exclude unnecessary files from
 Gemini analysis.
- Updating `.gitignore` to reflect the new structure and exclude
 sensitive files.
- Updating `codemagic.yaml` to reflect the new app locations.
- Adding a `make help` command to the root directory.
- Adding a `make install-git-hooks` command to install git hooks.
- Adding a `docs/02-codemagic-env-vars.md` file to document
 Codemagic environment variables.
- Adding a `docs/03-contributing.md` file to document
 contribution guidelines.
- Adding prototype placeholders to the internal launchpad.
- Updating the `README.md` file to reflect the new structure and
 provide updated instructions.

These changes improve the overall structure of the monorepo and
make it easier to develop, maintain, and scale the KROW Workforce
platform.

internal/launchpad/assets/documents/legacy/client-mobile-application/architecture.md

@@ -218,35 +218,3 @@ flowchart TD
         B5 --> E5[Display profile information];
     end
 ```
-
-## G. Replacing or Plugging in a New Backend: Considerations & Recommendations
-
-This section provides guidance on how to replace the current GraphQL + Firebase backend with a different backend solution.
-
-### Tightly Coupled Components
-
-*   **`ApiClient`:** This class is tightly coupled to `graphql_flutter`.
-*   **Firebase Auth:** The authentication logic is directly tied to the `firebase_auth` package.
-*   **BLoCs:** Some BLoCs might have direct dependencies on Firebase or GraphQL-specific models.
-
-### Abstraction Recommendations
-
-To make the architecture more backend-agnostic, the following abstractions should be implemented:
-
-*   **Repositories:** Create an abstract `Repository` class for each feature in the `domain` layer. The implementation of this repository will be in the `data` layer. The BLoCs should only depend on the abstract repository.
-*   **Authentication Service:** Create an abstract `AuthService` class that defines the methods for authentication (e.g., `signIn`, `signOut`, `getToken`). The implementation of this service will be in the `data` layer and will use the specific authentication provider (e.g., Firebase Auth, OAuth).
-*   **Data Transfer Objects (DTOs):** Use DTOs to transfer data between the data layer and the domain layer. This will prevent the domain layer from having dependencies on backend-specific models.
-
-### Suggested Design Improvements
-
-*   **Formalize Clean Architecture:** While the current architecture has elements of Clean Architecture, it could be more formally implemented by creating a clear separation between the `domain`, `data`, and `presentation` layers for all features.
-*   **Introduce Use Cases:** Introduce `UseCase` classes in the `domain` layer to encapsulate specific business operations. This will make the BLoCs simpler and more focused on state management.
-
-### Migration Strategies
-
-To replace the current backend with a new one (e.g., REST API, Supabase), follow these steps:
-
-1.  **Implement New Repositories:** Create new implementations of the repository interfaces for the new backend.
-2.  **Implement New Auth Service:** Create a new implementation of the `AuthService` interface for the new authentication provider.
-3.  **Update Dependency Injection:** Use dependency injection (e.g., `get_it` and `injectable`) to provide the new repository and auth service implementations to the BLoCs.
-4.  **Gradual Migration:** If possible, migrate one feature at a time to the new backend. This will reduce the risk of breaking the entire application at once.