Rebuild firmware scaffold for ESP32-C6/ESP-IDF, replacing NCS/Zephyr

The product pivoted away from a Matter-first nRF54L15 device to an
ESP32-C6/ESP-IDF/C++17 platform where behaviour is defined by a
Blockly-generated Lua program instead of custom firmware (see the
updated kvida meta-repo vision). Removes the west/NCS/Zephyr scaffold
and replaces it with:

- A pinned ESP-IDF v6.0.2 Docker build environment (Espressif's
  official image already bundles the toolchain, unlike NCS/west).
- A layered component structure (drivers -> sensors -> profiles ->
  lua_runtime -> transport) matching the new architecture principles,
  with per-component READMEs describing responsibilities.
- An A/B OTA + LittleFS partition table and a minimal main.cpp.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

components/drivers/CMakeLists.txt

@@ -0,0 +1,2 @@
+idf_component_register()
+

components/drivers/README.md

@@ -0,0 +1,5 @@
+# drivers
+
+Hardware abstraction: wraps ESP32-C6 peripherals (GPIO, ADC, I2C) behind a board-independent interface used by `sensors`. No dependency on other Kvida components.
+
+TODO: mounting the `storage` LittleFS partition (see `partitions.csv`) belongs here once a LittleFS component (e.g. `joltwallet/esp_littlefs` from the IDF Component Registry) is picked and pinned via `idf_component.yml`.

components/lua_runtime/CMakeLists.txt

@@ -0,0 +1,3 @@
+idf_component_register(
+    REQUIRES profiles transport
+)

components/lua_runtime/README.md

@@ -0,0 +1,5 @@
+# lua_runtime
+
+Executes the sandboxed Lua program (compiled from Blockly) that defines device behaviour. Exposes the Kvida API (e.g. `publish("temperature", 21.3)`) to Lua scripts; Lua never touches ESP-IDF or `transport` directly. `REQUIRES profiles transport`.
+
+TODO: needs an actual Lua interpreter dependency, pinned via `idf_component.yml` once a specific IDF Component Registry package/version is confirmed (not guessed here, same caution as pinning `west.yml`'s NCS revision previously).

components/profiles/CMakeLists.txt

@@ -0,0 +1,3 @@
+idf_component_register(
+    REQUIRES sensors
+)

components/profiles/README.md

@@ -0,0 +1,3 @@
+# profiles
+
+Exposes reusable sensor/actuator capabilities (reed switch, hall sensor, push button, pulse counter, analog input, DS18B20, BME280, leak sensor, PIR, generic I2C device) to the Lua runtime, backed by `sensors`. `REQUIRES sensors`.

components/sensors/CMakeLists.txt

@@ -0,0 +1,3 @@
+idf_component_register(
+    REQUIRES drivers
+)

components/sensors/README.md

@@ -0,0 +1,3 @@
+# sensors
+
+Turns raw `drivers` readings into typed sensor values (e.g. debounced contact state, calibrated analog readings). Knows values, not hardware. `REQUIRES drivers`.

components/transport/CMakeLists.txt

@@ -0,0 +1 @@
+idf_component_register()

components/transport/README.md

@@ -0,0 +1,11 @@
+# transport
+
+Wi-Fi connectivity, MQTT client, and Home Assistant MQTT Discovery payloads. Exposes a semantic `publish(topic, value)`-style API — application code (including Lua) never depends on MQTT directly, per the transport abstraction principle in `AGENTS.md`. No dependency on other Kvida components.
+
+Also owns Wi-Fi/MQTT configuration storage for now (not broken out into its own component since `AGENTS.md` doesn't call out a separate config layer — revisit if this grows).
+
+Future transports (Zigbee, Thread, Matter) should implement the same publish API as alternate backends behind this component's interface, without changing callers.
+
+TODO: built on ESP-IDF's own `esp_wifi` and `mqtt_client` (`esp-mqtt`) components once real code lands — both ship with ESP-IDF, no extra registry dependency needed.
+
+TODO: A/B OTA update-checking belongs here, driven by ESP-IDF's native `esp_ota_ops` against the `ota_0`/`ota_1` partitions in `partitions.csv` — no extra dependency needed either.