* fix: prevent spurious recovery notifications for private locations Fixed bug where private location monitors would send recovery notifications without prior degraded/error notifications. Root Cause: Private location notification logic was triggering notifications whenever the threshold was met (≥50% of locations in a status), regardless of whether the monitor's overall status had actually changed. Example Bug Scenario (3 locations): 1. All locations start active, monitor.status = 'active' 2. Location 1 becomes degraded (1/3 = 33% < 50%) - shouldTriggerIncident = false - No notification sent ❌ 3. Location 1 recovers to active (3/3 = 100% ≥ 50%) - shouldTriggerIncident = true - Recovery notification sent even though monitor.status was always 'active' ❌ The Fix: For private-only monitors, notifications now require BOTH: 1. Threshold met (shouldTriggerIncident = true) 2. Monitor status actually changing (monitor.status !== targetStatus) This matches the cloud monitor pattern in index.ts which checks monitor status before sending notifications (lines 168, 201, 237). Cloud monitors continue to work as before (threshold-based notifications) since they aggregate regions differently. Fixes notification asymmetry where users would see 'recovered' without seeing the initial 'degraded' or 'error' notification. * ci: apply automated fixes --------- Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>