fix(esp32): use runtime node_id from NVS in outgoing packets

[melodykke]

Summary

Fix an ESP32 firmware issue where outgoing packets could use the compile-time node ID instead of the runtime node ID loaded from NVS.

In multi-node setups, this could cause a provisioned board to still appear with the wrong node_id on the receiver side.

Root Cause

Some packet serialization paths were still using CONFIG_CSI_NODE_ID instead of g_nvs_config.node_id.

That meant NVS provisioning could succeed while transmitted packets still carried the compile-time default.

Changes

Use g_nvs_config.node_id consistently in outgoing packet paths.

Validation

Tested with a real ESP32-S3 setup.

• provisioned a board with node_id=2 via NVS
• rebuilt and reflashed firmware
• confirmed RuView then reported node_id=2 correctly

Impact

This makes runtime node provisioning behave correctly for multi-node deployments.

[ruvnet]

Code Review — PR #232

Recommendation: HOLD (partially superseded, scope creep)

Summary

This PR from @melodykke has two distinct parts:

Part 1 — Firmware: NVS runtime node_id (the stated purpose)
Replaces CONFIG_CSI_NODE_ID with g_nvs_config.node_id across 4 firmware files:

• csi_collector.c — packet serialization
• display_ui.c — UI node label
• edge_processing.c — compressed frame and vitals packets
• wasm_runtime.c — WASM output packets

Part 2 — Sensing server: Multi-node spatial fusion (~800 lines, unstated)
Adds an entire spatial fusion system to the sensing server:

• SpatialLayoutConfig with JSON node positions and zone definitions
• Per-node Esp32NodeState with independent signal processing pipelines
• Zone-based presence/motion/vital scoring with cross-node consensus
• FusionConsensus and FusionExplanation structs
• config/spatial-layout.json spatial layout file
• Docker config update

Security Assessment

• No security vulnerabilities found. The extern nvs_config_t g_nvs_config pattern is safe — it is initialized before use in app_main.
• Path concern: spatial-layout.json is loaded from disk via --spatial-config flag — no user-facing path traversal risk since it is a CLI argument, not a web endpoint.
• The adaptive_override refactor correctly decouples from AppStateInner, improving testability.

Conflict Assessment (ADR-069 through ADR-078)

• Part 1 (NVS node_id) is already on main. Commit 8a84748a8 ("fix(firmware): use NVS node_id instead of Kconfig constant") already made these exact same changes. Merging would conflict.
• Part 2 (spatial fusion) will conflict heavily with sensing-server/src/main.rs on main, which has had significant changes through ADR-069 (Cognitum pipeline), ADR-070+, and the recent v0.5.3 cross-node fusion work.

Code Quality Notes (Part 2)

• Good: Per-node state isolation prevents cross-contamination of temporal features between ESP32 nodes.
• Good: Zone scoring with geometric weighting is a sound approach.
• Concern: ~800 lines of new code added to an already large main.rs (3000+ lines). This should be extracted into separate modules (spatial.rs, fusion.rs).
• Concern: The fuse_esp32_update function is doing too much — it combines filtering, scoring, consensus, and explanation generation. Should be decomposed.

Recommendation

Part 1 is already merged. Part 2 introduces valuable multi-node fusion but:

1. Conflicts extensively with current main
2. Needs to be rebased onto current main
3. Should be split into a separate PR with proper module decomposition
4. Should be reviewed against our existing cross-node fusion work (v0.5.3, ADR-069)

Verdict: HOLD — Ask contributor to rebase and split the sensing-server changes into a separate PR.

[ruvnet]

Thanks @melodykke — the NVS node_id fix is already on main (8a84748). The multi-node spatial fusion concept is interesting but conflicts extensively with v0.5.3-v0.5.5 changes (cross-node fusion, ADR-069 Seed pipeline, ADR-075 MinCut person counting). Could you rebase and split the spatial fusion into a separate PR targeting the sensing-server only? Happy to review a rebased version.