fix(firmware): change promiscuous filter to ALL frames for CSI capture

[volkantasci]

Problem

ESP32-S3 (rev v0.2) CSI callback never fires after WiFi STA connects. yield=0pps permanently, even with RSSI -45 to -50 dBm indicating healthy WiFi.

Root Cause

Promiscuous filter was set to WIFI_PROMIS_FILTER_MASK_MGMT (management frames only). CSI is extracted from LTF fields present ONLY in DATA frames, not management frames. MGMT-only filter silences CSI entirely.

Fix

Change promiscuous filter from WIFI_PROMIS_FILTER_MASK_MGMT → WIFI_PROMIS_FILTER_MASK_ALL.

Verification

Tested on:

• Device: Heltec LoRa V3 (ESP32-S3FN8, 8MB flash, rev v0.2)
• AP: Zyxel_D631 (WPA3-SAE, channel 3, bgn, 20MHz)
• Result: yield went from 0 pps → 5-8 pps (SENSE_IDLE/SENSE_ACTIVE)

Risk

On busy WiFi networks (100+ data frames/sec) this may cause Core 0 crashes in wDev_ProcessFiq. Our network has low data traffic so this is safe. A future PR could implement adaptive filter toggling based on yield rate.

Fixes #521

[ruvnet]

Your root-cause is exactly right — WIFI_PROMIS_FILTER_MASK_MGMT starves CSI because the LTF fields live in DATA frames, and the Heltec then sits at yield=0pps. 👍

Heads-up on the filter change specifically (MASK_MGMT → MASK_ALL): main now addresses this with a safer, more targeted fix that may already unblock your Heltec without the MASK_ALL risk you flagged — worth rebasing against:

• csi_collector.c:640 csi_collector_enable_data_capture() upgrades the filter to MGMT | DATA (not ALL).
• main.c:424 calls it only when !has_display.
• display_is_active() (display_task.c:18) is AMOLED-specific — it returns true only after display_hal_init_panel() detects an RM67162/SH8601 panel.

The Heltec LoRa V3's display is an I²C SSD1306 OLED, not that AMOLED — so display_hal_init_panel() fails → has_display = false → enable_data_capture() runs → the Heltec gets MGMT|DATA → CSI flows. That should give you the same 5–8 pps without MASK_ALL.

Two reasons MGMT|DATA (gated) is preferable to an unconditional MASK_ALL here:

1. AMOLED-board regression — on an ADR-045 SPI-AMOLED node, MASK_ALL reintroduces the ESP32-S3 CSI crash: SPI flash cache race in wDev_ProcessFiq during promiscuous mode #396 wDev_ProcessFiq SPI-flash-cache crash that the !has_display gate exists to avoid. MASK_ALL is applied unconditionally, so it would crash those boards.
2. Busy-network risk — MASK_ALL also pulls CTRL + misc frames you don't need for CSI, adding the very interrupt load behind the Core-0 crash you noted. MGMT|DATA is the minimal set that still yields CSI.

The rest of this PR (C6 build overlay, ESP-NOW EMA offset smoother, the redact-secrets.py witness-bundle fix) is independent of the filter line — those stand on their own. Could you rebase onto current main and drop the MASK_ALL change (or, if a board genuinely needs DATA capture with an AMOLED active, gate it on panel type rather than unconditionally)? Happy to help verify once rebased.