SyncWordValid raised with HeaderValid in LoRa mode inflates irq_suppressed #4

What happens

On every received header the model raises SyncWordValid alongside HeaderValid:

• src/VirtualSX1262.cpp:150 — raiseIrq(kIrqHeaderValid | kIrqSyncWordValid);

raiseIrq() (src/VirtualSX1262.cpp:54-57) counts one irq_suppressed event whenever any bit in the call is masked off. MeshCore never enables bit 0x0008 — not in 1.16 (IrqMask 0x0272) and not in 1.17 (0x0276) — so every header counts as suppressed, even on a firmware that is configured correctly.

Why it matters

It accounts exactly for the figures in MeshBench/meshbench#745 (12 packets on the three-node link):

The difference between the versions is real (MeshCore fae48031, first in v1.17.0, adds PREAMBLE_DETECTED to the receive mask). But 1.17's 12 is entirely this artefact: a correctly configured firmware reports non-zero suppression, and anyone reading the count would conclude it is still missing interrupts.

Proposed fix

My understanding of the SX126x datasheet's IRQ table is that SyncWordValid is an FSK-mode interrupt, and that LoRa reports the header through HeaderValid. If that is confirmed against the table:

• raise kIrqHeaderValid alone in LoRa mode at line 150;
• add a test that a 1.17-style mask (0x0276) receiving a frame leaves irq_suppressed at 0, and a 1.16-style mask (0x0272) counts exactly one per frame.

Separately, irq_suppressed counts one per raiseIrq call rather than one per masked bit. Either is defensible, but the header comment on vsx_counters.irq_suppressed should say which.

Draft #3 changes the timing on the line above this call and keeps the SyncWordValid bit, so it would be worth settling this before #3 lands.