## Problem Summary
Windows native builds were failing while resolving the `ndarray-linalg` / OpenBLAS dependency chain because the workspace forced `openblas-static` everywhere. On Windows, that pulled `openblas-src` into a non-vcpkg build path that it does not support.
## Reproduction Conditions
- Windows 11
- Git Bash / MINGW64
- Rust/Cargo workspace build
- vcpkg and OpenBLAS installed locally
- Python 3.14
- Docker Desktop available
- RTX 3050 laptop GPU present
- Failure observed during `./install.sh`, Rust profile installation, and workspace compilation on the Windows native path
## Root Cause
The workspace previously pinned `ndarray-linalg` in the root Cargo manifest with `openblas-static` for all targets. That propagated into `lax -> openblas-src`, which then attempted an unsupported Windows build mode. The error surfaced as:
> `openblas-src v0.10.15: Non-vcpkg builds are not supported on Windows. You must use the 'system' feature.`
## Fix
This patch makes the backend choice explicit and target-specific:
- Windows uses `openblas-system`
- non-Windows targets keep `openblas-static`
- the default `ndarray-linalg` feature wiring in `wifi-densepose-signal` is made explicit with `dep:ndarray-linalg`
That preserves existing Linux/macOS behavior while making the Windows path use the system OpenBLAS/vcpkg-compatible route.
## Why `openblas-src` Failed on Windows
`openblas-src` does not support the non-vcpkg build path on Windows. When `ndarray-linalg` selected `openblas-static`, Cargo ultimately asked `openblas-src` to build or bundle OpenBLAS in a way that is unsupported on Windows. The `system` feature is the supported Windows path because it uses the system-provided OpenBLAS installation instead of the unsupported bundled/static path.
## Dependency / Backend Selection Changes
- Removed the workspace-wide `ndarray-linalg` backend pin from the root `Cargo.toml`
- Moved ownership of the `ndarray-linalg` dependency into `crates/wifi-densepose-signal/Cargo.toml`
- Selected `openblas-system` on Windows and `openblas-static` elsewhere
- Kept the signal crate’s default `eigenvalue` feature wired to the optional BLAS-backed dependency
## Validation
- `cargo check --workspace` completed successfully
- The workspace build now resolves `ndarray-linalg` without tripping the unsupported Windows OpenBLAS build path
## Expected Impact
- Windows users can build the workspace without hitting the `openblas-src` non-vcpkg failure
- Linux and macOS builds continue using the existing static/bundled behavior
- No runtime code, APIs, or signal-processing logic were changed
## Cargo.lock Considerations
- A local Cargo re-resolution was observed during validation
- No lockfile churn is included in this commit because the fix itself is manifest-only and the regenerated local lock delta was incidental to validation
## Changed Files
- `v2/Cargo.toml`
- `v2/crates/wifi-densepose-signal/Cargo.toml`
9660b23746