chore(repo): rename rust-port/wifi-densepose-rs → v2/ (flatten to one level) (#427)

The Rust port lived two directories deep (rust-port/wifi-densepose-rs/)
without any sibling under rust-port/ that warranted the extra level.
Move the whole workspace up to v2/ to match v1/ (Python) at the same
depth and shorten every cd / build command across the repo.

git mv preserves history for all tracked files. 60 files updated for
path references (CI workflows, ADRs, docs, scripts, READMEs, internal
.claude-flow state). Two manual fixes for relative-cd paths in
CLAUDE.md and ADR-043 that became wrong after the depth change
(cd ../.. → cd ..).

Validated:
- cargo check --workspace --no-default-features → clean (after target/
  nuke; the gitignored target/ was carried by the OS rename and had
  hard-coded old paths in build scripts)
- cargo test --workspace --no-default-features → 1,539 passed, 0 failed,
  8 ignored (same totals as pre-rename)
- ESP32-S3 on COM7 → still streaming live CSI (cb #40300, RSSI -64 dBm)

After-merge follow-up: contributors should `rm -rf v2/target` once and
let cargo regenerate from the new path.

v2/docs/adr/ADR-001-workspace-structure.md

@@ -0,0 +1,56 @@
+# ADR-001: Rust Workspace Structure
+
+## Status
+Accepted
+
+## Context
+We need to port the WiFi-DensePose Python application to Rust for improved performance, memory safety, and cross-platform deployment including WASM. The architecture must be modular, maintainable, and support multiple deployment targets.
+
+## Decision
+We will use a Cargo workspace with 9 modular crates:
+
+```
+wifi-densepose-rs/
+├── Cargo.toml                    # Workspace root
+├── crates/
+│   ├── wifi-densepose-core/      # Core types, traits, errors
+│   ├── wifi-densepose-signal/    # Signal processing (CSI, phase, FFT)
+│   ├── wifi-densepose-nn/        # Neural networks (DensePose, translation)
+│   ├── wifi-densepose-api/       # REST/WebSocket API (Axum)
+│   ├── wifi-densepose-db/        # Database layer (SQLx)
+│   ├── wifi-densepose-config/    # Configuration management
+│   ├── wifi-densepose-hardware/  # Hardware abstraction
+│   ├── wifi-densepose-wasm/      # WASM bindings
+│   └── wifi-densepose-cli/       # CLI application
+```
+
+### Crate Responsibilities
+
+1. **wifi-densepose-core**: Foundation types, traits, and error handling shared across all crates
+2. **wifi-densepose-signal**: CSI data processing, phase sanitization, FFT, feature extraction
+3. **wifi-densepose-nn**: Neural network inference using ONNX Runtime, Candle, or tch-rs
+4. **wifi-densepose-api**: HTTP/WebSocket server using Axum
+5. **wifi-densepose-db**: Database operations with SQLx
+6. **wifi-densepose-config**: Configuration loading and validation
+7. **wifi-densepose-hardware**: Router and hardware interfaces
+8. **wifi-densepose-wasm**: WebAssembly bindings for browser deployment
+9. **wifi-densepose-cli**: Command-line interface
+
+## Consequences
+
+### Positive
+- Clear separation of concerns
+- Independent crate versioning
+- Parallel compilation
+- Selective feature inclusion
+- Easier testing and maintenance
+- WASM target isolation
+
+### Negative
+- More complex dependency management
+- Initial setup overhead
+- Cross-crate refactoring complexity
+
+## References
+- [Cargo Workspaces](https://doc.rust-lang.org/cargo/reference/workspaces.html)
+- [ruvector crate structure](https://github.com/ruvnet/ruvector)

v2/docs/adr/ADR-002-signal-processing.md

@@ -0,0 +1,40 @@
+# ADR-002: Signal Processing Library Selection
+
+## Status
+Accepted
+
+## Context
+CSI signal processing requires FFT operations, complex number handling, and matrix operations. We need to select appropriate Rust libraries that provide Python/NumPy equivalent functionality.
+
+## Decision
+We will use the following libraries:
+
+| Library | Purpose | Python Equivalent |
+|---------|---------|-------------------|
+| `ndarray` | N-dimensional arrays | NumPy |
+| `rustfft` | FFT operations | numpy.fft |
+| `num-complex` | Complex numbers | complex |
+| `num-traits` | Numeric traits | - |
+
+### Key Implementations
+
+1. **Phase Sanitization**: Multiple unwrapping methods (Standard, Custom, Itoh, Quality-Guided)
+2. **CSI Processing**: Amplitude/phase extraction, temporal smoothing, Hamming windowing
+3. **Feature Extraction**: Doppler, PSD, amplitude, phase, correlation features
+4. **Motion Detection**: Variance-based with adaptive thresholds
+
+## Consequences
+
+### Positive
+- Pure Rust implementation (no FFI overhead)
+- WASM compatible (rustfft is pure Rust)
+- NumPy-like API with ndarray
+- High performance with SIMD optimizations
+
+### Negative
+- ndarray-linalg requires BLAS backend for advanced operations
+- Learning curve for ndarray patterns
+
+## References
+- [ndarray documentation](https://docs.rs/ndarray)
+- [rustfft documentation](https://docs.rs/rustfft)

v2/docs/adr/ADR-003-neural-network-inference.md

@@ -0,0 +1,57 @@
+# ADR-003: Neural Network Inference Strategy
+
+## Status
+Accepted
+
+## Context
+The WiFi-DensePose system requires neural network inference for:
+1. Modality translation (CSI → visual features)
+2. DensePose estimation (body part segmentation + UV mapping)
+
+We need to select an inference strategy that supports pre-trained models and multiple backends.
+
+## Decision
+We will implement a multi-backend inference engine:
+
+### Primary Backend: ONNX Runtime (`ort` crate)
+- Load pre-trained PyTorch models exported to ONNX
+- GPU acceleration via CUDA/TensorRT
+- Cross-platform support
+
+### Alternative Backends (Feature-gated)
+- `tch-rs`: PyTorch C++ bindings
+- `candle`: Pure Rust ML framework
+
+### Architecture
+```rust
+pub trait Backend: Send + Sync {
+    fn load_model(&mut self, path: &Path) -> NnResult<()>;
+    fn run(&self, inputs: HashMap<String, Tensor>) -> NnResult<HashMap<String, Tensor>>;
+    fn input_specs(&self) -> Vec<TensorSpec>;
+    fn output_specs(&self) -> Vec<TensorSpec>;
+}
+```
+
+### Feature Flags
+```toml
+[features]
+default = ["onnx"]
+onnx = ["ort"]
+tch-backend = ["tch"]
+candle-backend = ["candle-core", "candle-nn"]
+cuda = ["ort/cuda"]
+tensorrt = ["ort/tensorrt"]
+```
+
+## Consequences
+
+### Positive
+- Use existing trained models (no retraining)
+- Multiple backend options for different deployments
+- GPU acceleration when available
+- Feature flags minimize binary size
+
+### Negative
+- ONNX model conversion required
+- ort crate pulls in C++ dependencies
+- tch requires libtorch installation