Add persistent script storage + hot-reload, verified live

lua_runtime now loads the running script from a new LittleFS-backed
drivers::storage (joltwallet/littlefs, the project's fifth external
managed component -- mounts the "storage" partition already reserved
in partitions.csv), falling back to the compiled-in default script
only on first boot. transport exposes GET/POST /api/script -- raw Lua
text, not JSON, since json_helpers.h can't round-trip scripts safely
-- relayed to lua_runtime via the same callback-registration pattern
already used for LedColorHandler, keeping transport free of a
dependency on lua_runtime. lua_runtime_reload() persists and hot-swaps
to a fresh Lua state immediately, no reboot.

Verified on real ESP32-C6 hardware: script loads via kvida-sdk, an
edited script hot-reloads within one tick, and the edit survives a
power cycle (proving LittleFS persistence, not just an in-RAM change).

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

components/transport/README.md

@@ -34,6 +34,7 @@ Both httpd servers (the commissioning AP's and the settings server's) expose a s
 - `POST /api/wifi` (commissioning AP only) -- `{"ssid","password"}`, replaces the old form-urlencoded `/connect`.
 - `GET /api/status` (settings server) -- `{"device_id","wifi_connected","mqtt_connected"}`.
 - `GET /api/mqtt` / `POST /api/mqtt` (settings server) -- `{"host","port","username"[,"password"]}`; `GET` never returns the password.
+- `GET /api/script` / `POST /api/script` (settings server) -- the one endpoint in this API that is **not** JSON: the body is the raw Lua source as `text/plain`, both directions. Deliberate, not an oversight -- `json_helpers.h` is explicitly a non-escaping minimal parser, and Lua scripts routinely contain `"`, `\`, and newlines it can't round-trip safely. `transport` doesn't store or interpret the script itself (would mean depending on `lua_runtime`, breaking this component's "no dependency on other Kvida components" rule) -- it just relays through two function-pointer callbacks main.cpp wires up, `set_script_change_handler`/`set_script_provider`, the same pattern already used for `LedColorHandler`. `POST` reads the body in a loop up to an 8KB cap (`413` beyond that) since, unlike the small fixed-shape JSON bodies elsewhere here, `httpd_req_recv()` isn't guaranteed to return a script-sized body in one call.
 
 No JSON library ships with ESP-IDF v6.0.2 core (verified: no `cJSON`, no bundled `json` component). Given these payloads are tiny, flat, fixed-shape objects, `src/json_helpers.h` hand-rolls minimal `strstr`-based extraction rather than adding a 4th external registry dependency (already have `mdns`, `mqtt`, `led_strip`) -- explicitly not a general parser (no nesting, arrays, or escaping beyond what these specific request bodies need).