CRITICAL FIX: Persist hits BEFORE whitelisting checks

Bug #1 (CRITICAL): When IP is whitelisted or has 20+ established connections,
the 'continue' statement at line 2668/2675 skips the write_ip_data_to_file call.
This causes hits to increment in memory but NEVER persist to storage.

Result: On next scan, ip_data still has hits=0, and the IP stays stuck at 0 hits
forever, breaking the entire adaptive threshold system.

Fix: Write incremented hits to persistent storage IMMEDIATELY after incrementing,
BEFORE whitelist/legitimacy checks. This ensures:
1. Hits persists even if IP is skipped as whitelisted/legitimate
2. On next scan, load the correct incremented hits value
3. Adaptive threshold works correctly based on actual detection history

Data flow:
1. Load IP data from ip_data (includes current hits)
2. Increment hits: hits = 0 → 1
3. WRITE EARLY to persistent storage (before whitelisting)
4. Check whitelist/legitimacy (may continue)
5. If not whitelisted: continue with scoring
6. WRITE AGAIN with final score (line 2944)

Both writes include incremented hits, ensuring persistence survives.

Example: IP with 20 established connections
- Scan 1: Load hits=0, increment to 1, write (persists), whitelist check (continue)
- Scan 2: Load hits=1, increment to 2, write (persists), whitelist check (continue)
- Scan 3: Load hits=2, increment to 3, write (persists), whitelist check (continue)
- ...
- Scan 5: Load hits=4, increment to 5, threshold now 1, detected & scored!

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

modules/security/live-attack-monitor-v2.sh

@@ -2657,6 +2657,12 @@ monitor_network_attacks() {
                                 # This is the total lifetime detection count for this IP
                                 hits=$((hits + 1))
 
+                                # CRITICAL FIX: Always write incremented hits to persistent storage BEFORE whitelisting
+                                # Bug: If continue executes after incrementing hits, the incremented value is lost
+                                # This causes hits counter to never increase for whitelisted/legitimate IPs
+                                # Solution: Persist the increment immediately, then check whitelist
+                                write_ip_data_to_file "$ip" "$score|$hits|$bot_type|$attacks|$ban_count|$rep_score" 2>/dev/null &
+
                                 # Smart whitelisting: Skip IPs with MANY successful established connections
                                 # Only whitelist if IP has 20+ established connections (highly unlikely for attacker)
                                 # CRITICAL FIX: Use -w flag to match whole word (prevent partial IP matches)
@@ -2665,14 +2671,14 @@ monitor_network_attacks() {
                                 [ -z "$established_conns" ] && established_conns=0
                                 if [ "$established_conns" -ge 20 ]; then
                                     # IP has 20+ established connections = highly likely legitimate user
-                                    continue
+                                    continue  # Now safe - hits already persisted
                                 fi
 
                                 # Enhanced threat intelligence on first detection
                                 if [ "${hits:-0}" -eq 1 ]; then
                                     # Check if whitelisted service first
                                     if is_whitelisted_service "$ip" 2>/dev/null; then
-                                        continue  # Skip whitelisted IPs
+                                        continue  # Now safe - hits already persisted
                                     fi
 
                                     # Get threat intelligence in background to avoid slowdown