Add production polish and edge case handling for recurring tasks

Priority: Low

Estimated Effort: S (1 day)

User Value

Recurring tasks work reliably in edge cases and perform well with many templates.

Dependencies

Blocked by: #12821, #12822 (Core lazy persistence implementation)

Problem Context

After implementing the core lazy persistence functionality, the system needs production-ready polish to handle edge cases, optimize performance, and provide graceful error handling.

Solution Approach

Add performance optimizations, edge case handling, and error resilience to the lazy persistence system without changing the core functionality.

Acceptance Criteria

• [ ] Performance remains good with 10+ active recurring templates
• [ ] Proper date handling for month-end, leap years, timezone edge cases
• [ ] Memory usage stays reasonable for large date ranges (limit generation window)
• [ ] Graceful error handling when recurrence calculation fails
• [ ] Proper loading states for virtual instance generation
• [ ] No memory leaks when generating many virtual instances

Technical Scope

• Files: lib/recurring-tasks.ts, lib/recurrence.ts, task display components
• Dependencies: None (polish on existing functionality)
• Integration: Error handling, performance monitoring, existing recurrence logic

Out of Scope

• New recurrence patterns beyond what's already supported
• UI redesigns or major performance overhauls
• Changes to the core lazy persistence architecture

Implementation Notes

• Add reasonable limits on virtual instance generation (e.g., max 30 days forward)
• Implement proper error boundaries for recurrence calculation failures
• Add performance monitoring and optimization for template queries
• Handle edge cases in date calculations (month boundaries, leap years)
• Add proper loading states and error messages for users
• Ensure memory efficient virtual instance generation

Edge Cases to Handle

• Recurring tasks with invalid or corrupted recurrence data
• Date calculations that cross month boundaries (e.g., "31st of each month")
• Leap year handling for February 29th recurring tasks
• Timezone changes affecting recurring task scheduling
• Very long-running recurring tasks (years of history)
• Users with many concurrent recurring templates

INVEST Check

✅ Independent - Can be implemented after core functionality without other dependencies
✅ Negotiable - Specific optimizations can be prioritized
✅ Valuable - Ensures production reliability and user trust
✅ Estimable - Well-scoped polish work, 1 day
✅ Small - Focused on optimization and edge cases only
✅ Testable - Clear performance and reliability criteria