chore: remove overall release plan document and add mobile app release process documentation

docs/MOBILE/00-agent-development-rules.md

@@ -92,7 +92,7 @@ You have access to `prototypes/` folders. When migrating code:
 
 1.  **Extract Assets**: 
     * You MAY copy icons, images, and colors. But they should be tailored to the current design system. Do not change the colours and typgorahys in the design system. They are final. And you have to use these in the UI.
-      * When you matching colous and typography, from the POC match it with the design system and use the colors and typography from the design system. As mentioned in the `apps/mobile/docs/03-design-system-usage.md`.
+      * When you matching colous and typography, from the POC match it with the design system and use the colors and typography from the design system. As mentioned in the `apps/mobile/docs/02-design-system-usage.md`.
 2.  **Extract Layouts**: You MAY copy `build` methods for UI structure.
 3.  **REJECT Architecture**: You MUST **NOT** copy the `GetX`, `Provider`, or `MVC` patterns often found in prototypes. Refactor immediately to **Bloc + Clean Architecture with Flutter Modular and Melos**.
 
@@ -103,7 +103,7 @@ If a user request is vague:
 1.  **STOP**: Do not guess domain fields or workflows.
 2.  **ANALYZE**: 
  - For architecture related questions, refer to `apps/mobile/docs/01-architecture-principles.md` or existing code.
- - For design system related questions, refer to `apps/mobile/docs/03-design-system-usage.md` or existing code.
+ - For design system related questions, refer to `apps/mobile/docs/02-design-system-usage.md` or existing code.
 3.  **DOCUMENT**: If you must make an assumption to proceed, add a comment `// ASSUMPTION: <explanation>` and mention it in your final summary.
 4.  **ASK**: Prefer asking the user for clarification on business rules (e.g., "Should a 'Job' have a 'status'?").