Update dev notes and changelog

DEVELOPER.md

@@ -110,23 +110,30 @@ The welcome popup explains that the app:
 
 ## Core Components
 
-### 1. MapDataProvider
+### 1. MapDataProvider & Smart Area Caching
 
-**Purpose**: Unified interface for fetching map tiles and surveillance nodes
+**Purpose**: Unified interface for fetching map tiles and surveillance nodes with intelligent area caching
 
 **Design decisions:**
-- **Pluggable sources**: Local (cached) vs Remote (live API)
-- **Offline-first**: Always try local first, graceful degradation
+- **Single fetch strategy**: Uses PrefetchAreaService for smart 3x area caching instead of dual immediate/background fetching
+- **Spatial + temporal refresh**: Fetches larger areas (3x visible bounds) and refreshes stale data (>60s old)
+- **Offline-first**: Always try local cache first, graceful degradation
 - **Mode-aware**: Different behavior for production vs sandbox
 - **Failure handling**: Never crash the UI, always provide fallbacks
 
 **Key methods:**
-- `getNodes()`: Smart fetching with local/remote merging
-- `getTile()`: Tile fetching with caching
+- `getNodes()`: Returns cache immediately, triggers pre-fetch if needed (spatial or temporal)
+- `getTile()`: Tile fetching with enhanced retry strategy (6 attempts, 1-8s delays)
 - `_fetchRemoteNodes()`: Handles Overpass → OSM API fallback
 
-**Why unified interface:**
-The app needs to seamlessly switch between multiple data sources (local cache, Overpass API, OSM API, offline areas) based on network status, upload mode, and zoom level. A single interface prevents the UI from needing to know about these complexities.
+**Smart caching flow:**
+1. Check if current view within cached area AND data <60s old
+2. If not: trigger pre-fetch of 3x larger area, show loading state
+3. Return cache immediately for responsive UI
+4. When pre-fetch completes: update cache, refresh UI, report success
+
+**Why this approach:**
+Reduces API load by 3-4x while ensuring data freshness. User sees instant responses from cache while background fetching keeps data current. Eliminates complex dual-path logic in favor of simple spatial/temporal triggers.
 
 ### 2. Node Operations (Create/Edit/Delete)
 
@@ -186,7 +193,7 @@ Users expect instant response to their actions. By immediately updating the cach
 **Why underscore prefix:**
 These are internal app tags, not OSM tags. The underscore prefix makes this explicit and prevents accidental upload to OSM.
 
-### 5. Multi-API Data Sources
+### 5. Enhanced Overpass Integration & Error Handling
 
 **Production mode:** Overpass API → OSM API fallback
 **Sandbox mode:** OSM API only (Overpass doesn't have sandbox data)
@@ -195,8 +202,19 @@ These are internal app tags, not OSM tags. The underscore prefix makes this expl
 - **Production (Overpass)**: Zoom ≥ 10 (established limit)
 - **Sandbox (OSM API)**: Zoom ≥ 13 (stricter due to bbox limits)
 
-**Why different zoom limits:**
-The OSM API returns ALL data types (nodes, ways, relations) in a bounding box and has stricter size limits. Overpass is more efficient for large areas. The zoom restrictions prevent API errors and excessive data transfer.
+**Smart error handling & splitting:**
+- **50k node limit**: Automatically splits query into 4 quadrants, recursively up to 3 levels deep
+- **Timeout errors**: Also triggers splitting (dense areas with many profiles)  
+- **Rate limiting**: Extended backoff (30s), no splitting (would make it worse)
+- **Surgical detection**: Only splits on actual limit errors, not network issues
+
+**Query optimization:**
+- **Pre-fetch limit**: 4x user's display limit (e.g., 1000 nodes for 250 display limit)
+- **User-initiated detection**: Only reports loading status for user-facing operations  
+- **Background operations**: Pre-fetch runs silently, doesn't trigger loading states
+
+**Why this approach:**
+Dense urban areas (SF, NYC) with many profiles enabled can easily exceed both 50k node limits and 25s timeouts. Splitting reduces query complexity while surgical error detection avoids unnecessary API load from network issues.
 
 ### 6. Offline vs Online Mode Behavior
 

assets/changelog.json

@@ -1,4 +1,7 @@
 {
+  "1.2.5": {
+    "content": "• Smart area caching: Loads 3x larger areas and refreshes data every 60 seconds for much faster browsing\n• Enhanced tile loading: Increased retry attempts with faster delays - tiles load much more reliably\n• Improved error handling: Overpass queries now automatically split on timeouts and node limits\n• Better network status: Streamlined loading indicator that works with all data refresh types\n• Instant node display: Surveillance devices now appear immediately when data finishes loading\n• Node limit alerts: Get notified when too many devices are found (increase limit in settings to see more)"
+  },
   "1.2.4": {
     "content": "• New welcome popup for first-time users with essential privacy information\n• Automatic changelog display when app updates (like this one!)\n• Added Release Notes viewer in Settings > About\n• Enhanced user onboarding and transparency about data handling\n• Improved documentation for contributors"
   },