UC-026.5: Deep System Resilience

📖 1. Context & Problem Statement

1. API Limits & Multi-Page Syncing: Ingesting historical activities was limited to 1 page (30 items), flooding users with years-old rides in the Inbox, while a Delta Sync should only import recent updates.
2. Duplicate Activities & Clash Warning: High-latency multi-device submissions create duplicate entries. Syncing needs a conflict detection engine based on timestamp clashes.
3. Distance Anomalies: Errors in GPS files or manual edits can cause extreme mileage inputs (e.g. >300 km) that throw off component wear calculation unless protected.

⚙️ 2. Backend Logic & API (apps/api)

1. Incremental Sync Loop: Refactored GET /api/strava/sync to paginate through pages of length per_page dynamically until an incomplete page length is received.
2. Onboarding Seed Rule: On the user's initial sync (where lastStravaSyncDate is null), set the status of exactly the first 2 activities to 'PENDING' (to prevent inbox flood) and all remaining historical pages to 'HISTORY'.
3. Deep Resync & Bulk API: Added POST /api/strava/sync/deep for historical resyncing and POST /api/strava/activities/bulk for multi-row confirmations.

🎨 3. User Interface (apps/web)

1. Double-Ingestion Clash Banners: Activities starting within 5 minutes of each other are flagged with a prominent "Duplicate Timestamp Clash" alert in the Inbox.
2. Sanity Lock Bypass: Activities exceeding 300 km display an "Abnormal Distance" locked dialog. The user must manually click a confirmation checkbox to bypass the lock and confirm the ride.
3. Bulk Actions Dashboard: A sticky bottom HUD allows select-all checking to bulk confirm or ignore multiple activities at once.

🧪 4. Testing Requirements

• Integration Tests: Verify seed-rule logic on initial sync. Assert timestamp conflict grouping.