firmware: verify against actual target hardware, fix real conflicts

Researched the exact modules the user is building with and fixed three
concrete issues the earlier speculative firmware got wrong:

1. WiFi: confirmed the target board (Waveshare ESP32-P4-Module-DEV-KIT,
   chip ESP32-P4NRW32) bridges WiFi through an onboard ESP32-C6
   co-processor over a fixed 7-pin SDIO link (CLK18/CMD19/D0-14/D1-15/
   D2-16/D3-17/RESET54, cross-confirmed against Espressif's own
   esp-hosted-mcu docs). wifi_manager.c's esp_wifi_init()/esp_wifi_start()
   calls don't need to change — esp_wifi_remote/esp_hosted provide a
   drop-in-compatible API — but the component manifest (new
   main/idf_component.yml) and sdkconfig.defaults were missing entirely.

2. Real pin conflict: the presence sensor's original UART pins (17/18)
   directly collided with the SDIO CLK/D3 pins above — wiring it there
   would have broken WiFi, the sensor, or both. Moved to GPIO4/5.

3. Swapped placeholder parts for the user's actual hardware:
   - BME280 -> BMP280 (GY-BMP280 module): temp+pressure only, no humidity.
     Rewrote the driver rather than just renaming it — the old code would
     have read nonexistent humidity registers and reported garbage
     forever. 3.3V-only wiring note added (the BME280 assumption of
     5V-tolerant logic doesn't hold for this specific breakout).
   - LD2410 -> RD-03E (Ai-Thinker, not Hi-Link — a different manufacturer
     with a different, incompatible UART protocol). Rewrote the frame
     parser against the RD-03E's actual (if less-documented) 5-byte
     simple-report format. Reports numeric distance instead of a boolean,
     which better fits both the hardware's actual output and the backend's
     statistical anomaly detector.

README, CMakeLists.txt, and all cross-references updated to match.

firmware/esp32p4-sensor-node/main/wifi_manager.h

@@ -1,16 +1,20 @@
 // Wi-Fi station-mode connection management, using the credentials in
 // device_config.h.
 //
-// IMPORTANT hardware caveat (honesty note, not code): the ESP32-P4 SoC has
-// no integrated 2.4GHz radio -- real Wi-Fi on P4 hardware requires a
-// companion chip (e.g. ESP32-C6) wired via SDIO/SPI running "esp-hosted",
-// which presents this exact same esp_wifi/esp_netif API to application code.
-// This file is written against that standard API surface, so it should be
-// portable unchanged to a hosted-mode P4 board or to a Wi-Fi-native target
-// (e.g. `idf.py set-target esp32s3`) -- only sdkconfig / board wiring
-// differs, not this code. See README.md for the full explanation. This is
-// exactly the kind of thing nobody can verify without the real board, so
-// it's called out explicitly rather than glossed over.
+// IMPORTANT hardware note: the ESP32-P4 SoC has no integrated 2.4GHz radio.
+// Confirmed against the actual target hardware (Waveshare
+// ESP32-P4-Module-DEV-KIT, chip ESP32-P4NRW32): it pairs the P4 with an
+// onboard ESP32-C6 co-processor over a fixed 7-pin SDIO link, and Wi-Fi is
+// brought up via the `espressif/esp_wifi_remote` + `espressif/esp_hosted`
+// managed components (declared in main/idf_component.yml, configured in
+// sdkconfig.defaults). Those components provide a drop-in-compatible
+// esp_wifi_*/esp_netif_* API — this file's esp_wifi_init()/esp_wifi_start()
+// calls are unchanged from what they'd be on a Wi-Fi-native chip; only the
+// component manifest and sdkconfig differ, not this code. See README.md's
+// Wi-Fi section for the reserved SDIO pins (14-19, 54) and sdkconfig.defaults
+// for the exact config values — still unverified against real hardware
+// (nobody in this build has the physical board), but now backed by a
+// specific, sourced hardware architecture rather than a general caveat.
 
 #pragma once