fix(#505,#506): firmware v0.6.4 version CI gate + no-CSI-signal UI indicator

[ruvnet]

Summary

• Fixes v0.6.3-esp32 release ships a binary that internally identifies as 0.6.2 #505 — Firmware version string mismatch: bumps version.txt to 0.6.4 and adds a CI step that extracts the embedded esp_app_desc_t version from the built binary and fails the workflow if it doesn't match version.txt. Prevents silent version drift between code and flash.
• Fixes Your code appears to be fake #506 — Stale skeleton persists after ESP32 unplugged: adds csi_live: bool to PipelineOutput (true iff a CSI frame was received within the last 5 seconds), exposes it via /api/splats, and shows a red NO CSI SIGNAL banner in the viewer while clearing the skeleton when the signal is lost.

Changes

File	Change
firmware/esp32-csi-node/version.txt	0.6.2 → 0.6.4
.github/workflows/firmware-ci.yml	Add version-string verification step (both 8MB + 4MB matrix variants)
v2/crates/wifi-densepose-pointcloud/src/csi_pipeline.rs	Add last_csi_received: Option<Instant> + csi_live: bool in PipelineOutput
v2/crates/wifi-densepose-pointcloud/src/stream.rs	Expose csi_live in /api/splats JSON response
v2/crates/wifi-densepose-pointcloud/src/viewer.html	Red "NO CSI SIGNAL" overlay banner + clearSkeleton() when signal lost

Test plan

• cargo test --no-default-features — 15 passed, 0 failed
• cargo check — clean
• Firmware CI builds both 8MB + 4MB variants with version gate
• Simulate no-signal: disconnect ESP32, confirm banner appears within 5s and skeleton clears
• Reconnect ESP32, confirm banner disappears and skeleton resumes
• After merge: cut v0.6.4-esp32 tag to trigger firmware release CI

After merge

git tag v0.6.4-esp32
git push origin v0.6.4-esp32

This triggers the firmware CI to build and upload correctly-versioned binaries as release artifacts.

🤖 Generated with claude-flow

[proffesor-for-testing]

The version-string CI gate is a clean fix for #505 — extracting esp_app_desc_t.version from the built artifact and failing the workflow when it diverges from version.txt is exactly the right shape, and it'll catch this class of bug for every future release.

One thing the gate won't catch, though: in the current v0.6.3-esp32 release there's a separate problem that's orthogonal to the label drift — the 4mb-variant binary (cognitum-esp32s3-4mb-v0.6.3.bin, elf 090ef62b9…) has a Tmr Svc stack overflow that the standalone variant (cognitum-esp32s3-v0.6.3.bin, elf 8e62329d…) does not. Same partition table layout, same advertised version, runtime regression in one of the two builds. Detail and repro in #505: #505 (comment).

Today on a freshly-flashed ESP32-S3 N16R8 board:

• 4mb variant → reboot loop every ~5s, crash at first adaptive_ctrl medium tick
• Standalone → 0 crashes in multi-minute soak, CSI streaming clean to a remote aggregator

If you'd like, the v0.6.4 release that'll come out of this PR could fold in one of:

• Drop the -4mb- asset from the release until the regression is investigated (lowest-risk option for users picking by filename).
• Rebuild the 4MB target with the same Tmr Svc stack tuning as the standalone build — reuses the existing firmware-ci.yml matrix you already added in this PR, just needs whichever sdkconfig knob differs to converge.
• Leave both, but rename the 4mb asset so it's unambiguously "4MB-flash boards only" rather than reading like an alternative variant of the same binary.

Happy to test whichever build comes out of the next CI run against the same hardware where I reproduced the crash today.

🤖 Generated with Ruflo & AQE