docs: add comprehensive GiftedDialog architecture overview

Add detailed analysis of GiftedDialog component architecture including:
- DRY and SOLID principles compliance assessment
- Cognitive load analysis with before/after comparisons
- Architectural complexity remediation plan
- Phased implementation strategy (cognitive load → composable architecture)
- Component hierarchy and dependency analysis
- Performance and security considerations

The document provides actionable recommendations for reducing complexity
while maintaining functionality, with specific code examples and metrics.

.cursor/rules/documentation.mdc

@@ -11,3 +11,4 @@ workings of the system.
 4. Avoid **shallow, generic, or filler explanations** often found in
 AI-generated documentation.
 5. Aim for **clarity, depth, and usefulness**, so readers gain genuine understanding.
+6. Always check the local system date to determine current date.

.cursor/rules/markdown.mdc

@@ -312,3 +312,21 @@ Description of current situation or problem.
 **Last Updated**: 2025-07-09
 **Version**: 1.0
 **Maintainer**: Matthew Raymer
+
+
+### Heading Uniqueness
+
+- **Rule**: No duplicate heading content at the same level
+- **Scope**: Within a single document
+- **Rationale**: Maintains clear document structure and navigation
+- **Example**:
+
+  ```markdown
+  ## Features        ✅
+  ### Authentication
+  ### Authorization
+
+  ## Features        ❌ (Duplicate heading)
+  ### Security
+  ### Performance
+  ```

.cursor/rules/timesafari.mdc

@@ -151,7 +151,8 @@ on older/simpler devices.
 
 ## Project Architecture
 
-- The application must work on web browser, PWA (Progressive Web Application), desktop via Electron, and mobile via Capacitor
+- The application must work on web browser, PWA (Progressive Web Application),
+  desktop via Electron, and mobile via Capacitor
 - Building for each platform is managed via Vite
 
 ## Core Development Principles
@@ -222,14 +223,15 @@ on older/simpler devices.
 
 ### SOLID Principles
 
-- **Single Responsibility**: Each class/component should have only one reason to 
+- **Single Responsibility**: Each class/component should have only one reason to
   change
   - Components should focus on one specific feature (e.g., QR scanning, DID management)
-  - Services should handle one type of functionality (e.g., platform services, 
+  - Services should handle one type of functionality (e.g., platform services,
-  crypto services)
+    crypto services)
   - Utilities should provide focused helper functions
 
-- **Open/Closed**: Software entities should be open for extension but closed for modification
+- **Open/Closed**: Software entities should be open for extension but closed for
+  modification
   - Use interfaces for service definitions
   - Implement plugin architecture for platform-specific features
   - Allow component behavior extension through props and events