docs(p2.1): Create native plugin refactoring analysis document

Created docs/P2.1-NATIVE-REFACTORING-ANALYSIS.md with:
- Current state analysis (Android: 2,782 lines, iOS: 2,047 lines)
- Inventory of existing services (many already extracted!)
- Refactoring strategy: Focus on making plugin a thin adapter
- Next steps: Analyze remaining methods, create extraction plan

Key Finding: Many services already exist on both platforms.
Refactoring should focus on delegation to existing services
rather than creating new ones.

Verification:
- Analysis document created ✅
- Existing services inventoried ✅
- Strategy defined ✅

docs/P2.1-NATIVE-REFACTORING-ANALYSIS.md

@@ -0,0 +1,110 @@
+# Priority 2.1: Native Plugin Refactoring - Analysis
+
+**Purpose:** Analyze current native plugin structure and create refactoring plan to extract services from god classes.  
+**Owner:** Development Team  
+**Last Updated:** 2025-12-23  
+**Status:** analysis
+
+---
+
+## Current State
+
+### Android: `DailyNotificationPlugin.kt`
+- **Location:** `android/src/main/java/com/timesafari/dailynotification/DailyNotificationPlugin.kt`
+- **Size:** ~2,782 lines (per ChatGPT feedback)
+- **Type:** Capacitor Plugin class (extends `Plugin`)
+
+### iOS: `DailyNotificationPlugin.swift`
+- **Location:** `ios/Plugin/DailyNotificationPlugin.swift`
+- **Size:** ~2,047 lines (per ChatGPT feedback)
+- **Type:** Capacitor Plugin class (extends `CAPPlugin`)
+
+---
+
+## Refactoring Goals
+
+### Target Services (from ChatGPT feedback)
+
+1. **SchedulerService** - Schedule management logic
+2. **PermissionService** - Permission handling
+3. **Power/ExactAlarmService** - Power management and exact alarm handling
+4. **ReactivationService** - Cold start recovery and reactivation
+5. **RollingWindowService** - Rolling window and rate limiting
+6. **Storage/StateRepository** - Database and state management
+7. **FetcherBridge** - Native fetcher registration and calling
+
+### Principles
+
+- **Thin Plugin Adapter**: Plugin class should only:
+  - Parse/validate input
+  - Call platform service
+  - Map exceptions to plugin errors
+- **Service-Oriented**: Real logic lives in services
+- **Testability**: Services should be independently testable
+- **No Breaking Changes**: Maintain existing API surface
+
+---
+
+## Analysis Steps
+
+1. **Inventory Current Methods** - List all methods in both plugin classes
+2. **Identify Service Boundaries** - Group methods by logical service
+3. **Check Existing Services** - See what's already extracted
+4. **Create Extraction Plan** - Define safe, incremental extraction order
+5. **Define Service Interfaces** - Establish contracts for each service
+
+---
+
+## Analysis Results
+
+### Good News: Many Services Already Extracted!
+
+Both platforms have already extracted significant functionality into services:
+
+#### Android Services Already Exist:
+- ✅ `PermissionManager.java` - Permission handling
+- ✅ `DailyNotificationScheduler.java` - Scheduling logic
+- ✅ `ReactivationManager.kt` - Cold start recovery
+- ✅ `DailyNotificationRollingWindow.java` - Rolling window logic
+- ✅ `DailyNotificationStorage.java` - Storage abstraction
+- ✅ `DailyNotificationExactAlarmManager.java` - Exact alarm handling
+- ✅ `NativeNotificationContentFetcher.java` - Fetcher interface
+- ✅ `DailyNotificationPerformanceOptimizer.java` - Performance optimization
+- ✅ `TimeSafariIntegrationManager.java` - Integration orchestration
+
+#### iOS Services Already Exist:
+- ✅ `DailyNotificationScheduler.swift` - Scheduling logic
+- ✅ `DailyNotificationReactivationManager.swift` - Recovery
+- ✅ `DailyNotificationRollingWindow.swift` - Rolling window
+- ✅ `DailyNotificationStorage.swift` - Storage abstraction
+- ✅ `DailyNotificationPowerManager.swift` - Power management
+- ✅ `DailyNotificationStateActor.swift` - Thread-safe state
+- ✅ `DailyNotificationBackgroundTaskManager.swift` - Background tasks
+
+### Remaining Work
+
+The plugin classes still contain:
+1. **Direct database access** - Should use Storage service
+2. **Business logic** - Should delegate to services
+3. **Error handling** - Should use ErrorHandler service
+4. **Validation logic** - Should be in service layer
+5. **Orchestration** - Should use IntegrationManager (Android) or similar (iOS)
+
+### Refactoring Strategy
+
+Since many services already exist, the refactoring should focus on:
+1. **Removing direct service instantiation** from plugin methods
+2. **Delegating all business logic** to existing services
+3. **Making plugin class a thin adapter** that only:
+   - Parses/validates input
+   - Calls service methods
+   - Maps exceptions to plugin errors
+4. **Consolidating duplicate logic** into services
+
+## Next Steps
+
+1. ✅ Inventory existing services (DONE)
+2. ⏭️ Analyze plugin methods to identify what still needs extraction
+3. ⏭️ Create extraction plan focusing on delegation, not new services
+4. ⏭️ Implement refactoring in small batches
+