feat(firmware): report the TX-path counters, so buffer questions are testable

[clonea1]

A node that cannot transmit says so only to a serial console it does not have.
s_send_fail -- the count of datagram sends that failed because lwIP could not
allocate a pbuf, which is the ENOMEM signature -- was reachable only as an
ESP_LOGW line, and only for the FIRST FIVE failures. On a board mounted to a
wall that is the same as not reporting it.

The consequence is not that the TX path is unmonitored; it is that any question
about transmit buffering is UNTESTABLE in a deployed fleet. An upstream change
raising CONFIG_ESP_WIFI_DYNAMIC_TX_BUFFER_NUM cannot be validated or refuted by
anyone who cannot see the counter it is meant to move.

Sync packet proto v3 appends three u32 counters, monotonic since boot:

[38..41] send_fail   sends that failed to allocate a buffer
[42..45] rate_skip   frames suppressed by the 20 ms send cap (50 Hz ceiling)
[46..49] early_drop  callbacks discarded by the early rate gate

The two skip counters are here because send_fail alone cannot distinguish a
healthy radio from one whose rate limiters are working so hard that nothing
ever reaches the failing path. A zero send_fail beside a large rate_skip means
the cap is holding the line, not that there is headroom -- and that is exactly
the state this fleet is in.

Guarded on BOTH version and length when parsed. A padded v2 datagram is the
hazard: long enough to reach byte 49, containing nothing meaningful there.
Fabricated counters are worse than absent ones, because a non-zero send_fail
would be read as evidence of the very fault under investigation.

Backward compatible in both directions. An older sink ignores the tail; a v1 or
v2 node reports no counters and is read as such rather than as zeros.

---

Rebased onto current main before opening: staged before today's seven merges, so it needed replaying to avoid reading as a revert of them. Clean rebase, no files deleted.

[clonea1]

Converting this to a draft — it is over-scoped and blocked, and I would rather say so than leave it sitting in the queue failing CI.

Why the fuzz job fails. The commit adds thermal.h, esp_system.h and esp_heap_caps.h to csi_collector.c along with node-health fields (heap, reset reason, thermal state). The fuzz target compiles the real csi_collector.c against test/stubs/, which has none of those headers, so it fails to build. Same root cause as #1805.

It also carries work that is not TX counters. As staged this branch bundles four separate things:

1. the TX-path counters (send_fail, rate_skip, early_drop) — the actual subject
2. the CSI frame wire v2/v3 change, which feat(wire): carry transmitter and transmission identity in the CSI frame #1805 already covers
3. node-health fields in the sync packet
4. the ADR-345 seqdiag probe

And it is blocked regardless. The counters live at sync-packet bytes [38..49], but this repository's sync packet is 32 bytes at proto v1. They cannot be carried until the packet is extended, which is #1807 (hardware-sync-packet). Scoping this branch today would produce a correct PR that still could not merge.

Plan: land #1807 first, then re-cut this against it carrying only the counters and their parser. I will un-draft it then.

My fault for opening it in this state — I screened the batch on whether each branch rebased cleanly and deleted nothing, which does not catch a commit that was scoped loosely when it was staged.