Fix 5 memory leaks in WiFiScan.cpp

[tropicsquirrel]

Summary

Fixes 5 memory leaks, as reported by getFreeHeap() in WiFiScan.cpp found during testing. Each leak causes heap to shrink by a few KB per scan cycle, eventually leading to instability on long-running devices.

Fixes

1. generateRandomName() result not freed — In GetUniversalAdvertisementData(), the Microsoft Swiftpair case calls generateRandomName() (the no-arg version in utils.h) which returns a malloc'd string. The result was never freed, leaking ~6 bytes per advertising cycle (~100x/sec during spam).

2. AccessPoint.stations not freed in clearAPs() — Each AccessPoint has a heap-allocated LinkedList<uint16_t>* stations. clearAPs() removes list nodes but never deletes the inner stations lists, leaking ~24+ bytes per AP per scan cycle.

3. AccessPoint.stations not freed in RunAPScan() — Same issue: delete access_points destroys the outer list but doesn't follow the stations pointers.

4. probe_req_ssids never cleared on scan stop — The list is only cleared when starting WIFI_SCAN_PROBE, but probe requests are captured by multiple sniffer modes (beacon, deauth, EAPOL). Without clearing on stop, the list grows indefinitely across scan cycles.

5. airtags and flippers never cleared on scan stop — Both lists accumulate entries during BT scans but are never cleared, growing across scan cycles.

Testing

Tested on ESP32-S3 (8MB PSRAM).

• Before fix: heap dropped 5-14KB per scan cycle.
• After fix: heap stable within ±2KB across 5 consecutive full scan cycles.
• Note: 'scan cycle' includes the following, but the test plan (below) slims this list down significantly:
  • SSID Management
  • AP Scan
  • Beacon Sniff
  • Probe Sniff
  • Deauth Sniff
  • PMKID Sniff
  • Beacon List Attack
  • Random Beacon Spam
  • Rick Roll
  • BT Scan All
  • Sour Apple
  • Swiftpair Spam
  • BLE Spam All

Test plan

• Build for ESP32-S3 and ESP32 targets — verify no compile errors
• Run WiFi AP scan 3+ times — verify heap stays stable
• Run BT scan 3+ times — verify heap stays stable
• Run Swiftpair spam 3+ times — verify heap stays stable
• Verify clearAPs() still returns correct count