feat(c6): ESP-NOW cross-node sync — D1 workaround for broken 15.4 RX

After 5 systematic experiments confirmed the 802.15.4 RX path is
unfixable from user code in this IDF v5.4 + C6 combination (D1), add a
parallel sync transport over ESP-NOW. Same TS_BEACON protocol, same
public API (c6_sync_espnow_get_epoch_us / is_valid / is_leader), but
runs on the WiFi MAC layer that ESP-IDF fully supports across every
ESP32 family.

The 802.15.4 code stays in source for when the IDF driver is fixed.
ESP-NOW is the working primary today.

Empirical (single-board COM9 — other 3 boards dropped off USB during
the experiment):
- c6_sync_espnow_init() succeeds: "init done local_id=… leader=
  yes(candidate) period=100ms"
- TX path 100% reliable: tx#101 fail=0 over ~15s at 100ms cadence
- RX awaiting cross-board test once USB-enumeration is restored

Trade vs. 802.15.4 design:
- Loses: "frees WiFi airtime for CSI" property
- Gains: known-working RX path, cross-target (S3 and C6 both)
- Same API surface — consumers swap transports without code change

Files:
- main/c6_sync_espnow.{h,c} — new module, ~210 lines
- main/CMakeLists.txt        — add to SRCS (always built, used on any target)
- main/main.c                — init after WiFi STA up, skip on QEMU mock
- test/capture-3board-experiment.py — surface c6_espnow log lines
- docs/WITNESS-LOG-110.md    — new §D-workaround documenting the pivot

Ref: ruvnet/RuView#762 / D1 known-issue / draft PR #764

Co-Authored-By: claude-flow <ruv@ruv.net>

firmware/esp32-csi-node/main/CMakeLists.txt

@@ -13,6 +13,8 @@ set(SRCS
     "c6_twt.c"
     "c6_timesync.c"
     "c6_lp_core.c"
+    # ADR-110 D1 workaround — ESP-NOW cross-node sync (works on S3+C6)
+    "c6_sync_espnow.c"
 )
 
 # ESP-IDF v6+: headers must resolve via explicit REQUIRES (no implicit deps).