docs(privshield): rebrand project to "WiFi Veil"

Adopt "WiFi Veil" as the product name across all user-facing surfaces, keeping
VEIL (Verifiable Emission-shaping for Identity-Leakage prevention) as the
technical codename it's built on. Only prose, titles, descriptions, and the
console UI change — no code identifiers, file names, crate/npm `name` fields,
or the deterministic proof witness are touched, so `cargo test` and the C-core
host test are unaffected.

- Crate & research READMEs: title + defining line now "WiFi Veil (codename VEIL — …)".
- Cargo.toml / package.json / plugin.json descriptions: "WiFi Veil …".
- Console UI (veil-console.html): title, brand, and copy say "WiFi Veil".
- Firmware tree (README, per-provider READMEs, BUILD/INTEGRATION/MEASUREMENT):
  "WiFi Veil protector/core/shield".
- Harness manifest: recomputed SHA-256 digests for the four changed packaged
  files (README, package.json, CLAUDE.md, plugin.json) — all verified consistent.

Co-Authored-By: claude-flow <ruv@ruv.net>
Claude-Session: https://claude.ai/code/session_01WEXNqzs7UsfNFBcP5yW21p

firmware/privshield/README.md

@@ -1,8 +1,8 @@
-# VEIL privacy shield — end-to-end hardware implementation
+# WiFi Veil privacy shield — end-to-end hardware implementation
 
-This tree is the **hardware/firmware realization** of the VEIL compliant-waveform
+This tree is the **hardware/firmware realization** of the WiFi Veil compliant-waveform
 privacy shield (crate `wifi-densepose-privshield`, ADR-288; hardware program
-ADR-290). It takes VEIL from a synthetic reference model toward real silicon
+ADR-290). It takes WiFi Veil from a synthetic reference model toward real silicon
 across multiple hardware providers.
 
 > **Evidence discipline (read this first).** Everything here is **build-only /
@@ -64,19 +64,19 @@ across multiple hardware providers.
 ## Feasibility matrix
 
 Grades reflect *capability to actually shape the beamforming-feedback surface*
-(the waveform VEIL must touch), **not** effort. Each grade is taken from that
+(the waveform WiFi Veil must touch), **not** effort. Each grade is taken from that
 provider's own README, produced by a hardware research agent; the effort/blocker
 reality is in the "Why" column. All rows are `SYNTHETIC / L0` — build-only, no
 silicon, no captured log.
 
 | Provider | Grade | Can it shape the BF-feedback surface? | Why |
 |---|:---:|---|---|
-| **openwifi** (Zynq + AD9361, open PHY/MAC) | **B** | **Yes — the only full path.** Capability ceiling **A**; graded B for effort **D**. | Only platform exposing the whole PHY/MAC on FPGA, so a keyed rotation *and its inverse* are physically reachable. But it ships SISO 802.11a/g/n with **no native explicit beamforming** (no NDP sounding, no SVD `V`, no compressed report), so VEIL is realized as the client-transparent per-packet keyed unitary on the TX spatial-mapping stage — which requires **new HDL + a 2nd TX chain + a Vivado rebuild**. Carries the P5 measurement protocol. |
+| **openwifi** (Zynq + AD9361, open PHY/MAC) | **B** | **Yes — the only full path.** Capability ceiling **A**; graded B for effort **D**. | Only platform exposing the whole PHY/MAC on FPGA, so a keyed rotation *and its inverse* are physically reachable. But it ships SISO 802.11a/g/n with **no native explicit beamforming** (no NDP sounding, no SVD `V`, no compressed report), so WiFi Veil is realized as the client-transparent per-packet keyed unitary on the TX spatial-mapping stage — which requires **new HDL + a 2nd TX chain + a Vivado rebuild**. Carries the P5 measurement protocol. |
 | **openwrt** (Linux `mac80211`; mt76 / ath9k / ath1x) | **C** | **Partial — coarse compliant knobs only.** | The per-packet keyed unitary on the compressed-BF angles / LTF precoder is generated **inside the WiFi MCU firmware blob** on every mainstream AP part (Qualcomm ath10k/11k/12k, MediaTek mt76/mt7915) — userspace never touches the pre-TX `V`. Reachable from userspace: TX antenna-map perturbation, hostapd sounding-cadence jitter, beamformer-capability toggles. **ath9k** (802.11n, register-open) is the one credible driver-patch route toward B. |
 | **nexmon** (Broadcom/Cypress C-firmware patch; e.g. BCM43455c0) | **C** | **Read = A (solved); write = C/C-.** | *Reading* the compressed-BF angles is already solved (nexmon_csi + Wi-BFI, no firmware change). *Shaping the transmitted* report is graded C: the report is emitted by the proprietary **D11 real-time core** ~10 µs after the NDP, from hardware-updated internal memory — *below* the ARM firmware where Nexmon's C hooks live. Plausible, deep, firmware-version-specific, unproven here. |
 | **esp32** (Espressif ESP-IDF) | **F** / **B** | **F** as a self-protecting node; **B** as a supporting device. | The BF-report is emitted by the **closed `esp-phy-lib` blob** with no ESP-IDF hook to intercept or rotate it (`esp_wifi_80211_tx` won't hand-craft sounding feedback) — so **F (infeasible)** for shaping its own feedback. It earns **B (build-only)** in three legitimate, compliance-only supporting roles: **sensing detector** (CSI-rate trigger for the AP-side shield) and **RIS controller** (drive an external passive reconfigurable surface — the honest way ESP32 "helps scramble", via an external surface, never its own PHY). |
 
-**Reading the grades.** Only **openwifi** can host the full keyed-reversible VEIL
+**Reading the grades.** Only **openwifi** can host the full keyed-reversible WiFi Veil
 design end-to-end (and only after real HDL work). **openwrt** and **nexmon** are
 partial: the exact angles are blob-/ucode-locked on commodity silicon, leaving
 either coarse compliant perturbations (openwrt) or a deep, unproven ucode-adjacent
@@ -88,7 +88,7 @@ external surface — never by shaping its own transmission.**
 
 ## Two firmware variants
 
-- **Keyed-reversible** (VEIL's ~98%-throughput design): the protector rotates and
+- **Keyed-reversible** (WiFi Veil's ~98%-throughput design): the protector rotates and
   the associated receiver undoes it with the shared key — needs changes on
   **both** ends + key agreement. Best result; needs an open PHY (openwifi) for a
   true demo, or the client-transparent AP-side variant below.