fix(firmware): stop truncating HE20 CSI to half its subcarriers on C6/C5

[clonea1]

What is wrong

EDGE_MAX_SUBCARRIERS is 128 (edge_processing.h:36). An ESP32-C6 or C5
capturing HE20 produces 256 subcarriers. Everything past 128 is discarded.

The loss is silent. No warning, no error, no counter — the edge pipeline simply
operates on half the channel and reports normally. On an S3 (64-bin HT20) the
cap is never reached, so this only appears on newer silicon, where it looks like
poor sensitivity rather than a truncation.

The fix

Raise the cap to 256 so an HE20 frame survives intact.

Cost

Buffers sized by this constant double. That is the honest trade and worth
stating plainly rather than burying: the alternative is that half of every HE20
capture is thrown away on the hardware most likely to be used for new builds.

Testing

Built for esp32c6 with ESP-IDF v5.4 in the espressif/idf:v5.4 container.

[ruvnet]

Confirmed real: `EDGE_MAX_SUBCARRIERS` (128) silently truncates HE20 frames from C6/C5, which produce 256 subcarriers — and `process_frame()` just discards everything past 128 with no warning or counter. The fix's mechanism (conditional buffer sizing via `CONFIG_SOC_WIFI_HE_SUPPORT`) is consistent with how `csi_collector.c` already handles the same HE-capable/non-HE split for its own struct layout, so this isn't a new pattern — good. Correctly scoped to HE-capable chips only, so no wasted RAM on S3.

One gap: `fuzz_edge_enqueue.c` still hardcodes its own local `EDGE_MAX_SUBCARRIERS 128` and won't exercise the new 256-subcarrier path, so there's no regression test proving a 256-subcarrier frame is actually now accepted end-to-end. Worth adding before merge, or at minimum updating the fuzz harness's local constant so it doesn't silently drift from the real one.

[clonea1]

Hardware evidence, for the record now that this has merged. Captured from a real ESP32-C6 (e8:f6:0a:fc:bf:a0, node 7 of a nine-board fleet, IDF v5.4) over USB serial.

The premise holds: a C6 does deliver 256-bin HE20 frames.

I (20540) csi_collector: CSI cb #800:  len=512 rssi=-88 ch=11
I (22580) csi_collector: CSI cb #900:  len=512 rssi=-74 ch=11
I (35320) csi_collector: CSI cb #1500: len=512 rssi=-72 ch=11

len=512 bytes = 256 subcarriers x 2 bytes I/Q, exactly as the fix assumed.

And with the 256 grid in place, nothing is rejected. The node reports its edge-pipeline counters over the wire:

node 7: {'frames_processed': 2526, 'frames_rejected': 0}

frames_rejected counts frames discarded by process_frame()'s n_subcarriers > EDGE_MAX_SUBCARRIERS guard. Zero, sustained, on the part that could not process anything before.

One correction to the commit message, from the measurement.

It says "on C6 every frame was rejected and the whole edge pipeline ... silently did nothing". The C6 actually delivers a mix, and the pooled distribution over 44 sampled callbacks is:

len=512 -> 256 subcarriers :  37  (84.1%)
len=128 ->  64 subcarriers :   7  (15.9%)

So under the old 128 grid roughly 84% of frames were rejected, not 100% — the 64-bin frames always fit and were processed normally. The pipeline was running at about a sixth of its input rather than being dead.

That is still a serious bug, and it arguably explains why it went unnoticed for so long: vitals and presence kept producing something, just from a small and biased subset of frames, so nothing downstream looked obviously broken.

Two follow-ups from this:

• fix(firmware): include sdkconfig.h in edge_processing.h, and pin the subcarrier grid #1802 fixes a latent form of the same bug that merged with this PR: edge_processing.h switches on CONFIG_SOC_WIFI_HE_SUPPORT but never includes sdkconfig.h, so a translation unit reaching it without that header already in scope silently selects the 128 grid again. It works today only by accident of include order.
• The frames_processed / frames_rejected counters used above are not upstream yet. They exist so this class of failure announces itself instead of having to be found with a cable — processed == 0 && rejected > 0 names a mis-sized grid exactly. They sit on top of sync-packet proto v2/v3, which this repository does not have, so they need those upstreamed first.