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

docs/research/privacy-shield/README.md

@@ -1,10 +1,11 @@
-# Privacy Shield Research Bundle — VEIL
+# Privacy Shield Research Bundle — WiFi Veil
 
-**VEIL** (Verifiable Emission-shaping for Identity-Leakage prevention) is a
-privacy *firewall* for WiFi sensing: it prevents unauthorized identity and
+**WiFi Veil** (codename **VEIL** — Verifiable Emission-shaping for
+Identity-Leakage prevention) is a privacy *firewall* for WiFi sensing: it
+prevents unauthorized identity and
 activity inference from a room's WiFi while preserving normal communications. It
 is the **countermeasure** counterpart to [BFLD](../BFLD/) — where BFLD *detects*
-when beamforming feedback becomes identifying, VEIL *acts* by shaping the node's
+when beamforming feedback becomes identifying, WiFi Veil *acts* by shaping the node's
 own compliant waveform (channel sounding, precoder phase, beam/feedback
 schedules) so identity and activity inference fail, while a legitimate receiver
 sees an essentially unchanged link.
@@ -21,14 +22,14 @@ transmission (the statutory definition of jamming, 47 U.S.C. §333/§302a).
 | File | Purpose |
 |------|---------|
 | [01-sota-survey.md](01-sota-survey.md) | State of the art: identity/activity inference attacks (BFI + CSI), the IEEE 802.11bf-2025 standard, and privacy-preserving countermeasures |
-| [02-threat-model.md](02-threat-model.md) | Adversary classes, what VEIL defends and what it explicitly does not, trust boundary |
+| [02-threat-model.md](02-threat-model.md) | Adversary classes, what WiFi Veil defends and what it explicitly does not, trust boundary |
 | [03-countermeasure-design.md](03-countermeasure-design.md) | The compliant waveform controls, the separable-subspace principle, keyed Givens-rotation shield, and how it maps to the crate |
 | [04-compliance-and-regulatory.md](04-compliance-and-regulatory.md) | The legal line between compliant waveform control and jamming, with statutory citations |
 | [05-experiment-protocol.md](05-experiment-protocol.md) | The attacker-vs-protector experiment: metrics, acceptance bar, reproducer, and results |
 | [06-market-and-buyers.md](06-market-and-buyers.md) | First buyers, procurement drivers, competitive landscape, and the standards-body gap |
 | [07-implementation-and-roadmap.md](07-implementation-and-roadmap.md) | Crate layout, reuse map, hardware path, phased rollout, and open problems |
 | [08-optimization.md](08-optimization.md) | Hyper-optimization: throughput-optimal feedback resolution, minimum robust mixing budget, Pareto frontier, and the adopted config |
-| [09-sota-update-2026.md](09-sota-update-2026.md) | 2025–2026 SOTA update (verified, cited): stronger attacks (BFI→CSI reconstruction, through-wall vitals, keystroke), validated compliant defenses, and the derived VEIL improvement backlog |
+| [09-sota-update-2026.md](09-sota-update-2026.md) | 2025–2026 SOTA update (verified, cited): stronger attacks (BFI→CSI reconstruction, through-wall vitals, keystroke), validated compliant defenses, and the derived WiFi Veil improvement backlog |
 
 Formal decision: [ADR-288](../../adr/ADR-288-veil-privacy-shield-compliant-waveform.md).
 Reference implementation: [`v2/crates/wifi-densepose-privshield`](../../../v2/crates/wifi-densepose-privshield).
@@ -60,9 +61,9 @@ Reference implementation: [`v2/crates/wifi-densepose-privshield`](../../../v2/cr
    cannot coexist with wanted WiFi. The whitespace is a **selective, coexisting,
    software/PHY** shield.
 
-4. **The VEIL mechanism.** Identity leaks through the *fine* cross-subcarrier
+4. **The WiFi Veil mechanism.** Identity leaks through the *fine* cross-subcarrier
    phase structure of a beamforming report; throughput rides the *dominant*
-   beam direction. These are (mostly) separable subspaces. VEIL composes extra
+   beam direction. These are (mostly) separable subspaces. WiFi Veil composes extra
    **keyed Givens rotations** over the fine subspace only. The rotation is
    *orthogonal* (energy-preserving ⇒ not jamming), *keyed per session* (the
    legitimate receiver inverts it ⇒ throughput preserved), and *fresh each
@@ -79,9 +80,9 @@ Reference implementation: [`v2/crates/wifi-densepose-privshield`](../../../v2/cr
    [08-optimization.md](08-optimization.md)). Reproduce:
    `cargo test -p wifi-densepose-privshield`.
 
-6. **Scope, honestly.** VEIL defends against a *third-party passive sniffer*. It
+6. **Scope, honestly.** WiFi Veil defends against a *third-party passive sniffer*. It
    does **not** hide identity from the associated AP (that party holds the key)
-   — that is BFLD's detection/policy problem. VEIL is a reference model, not
+   — that is BFLD's detection/policy problem. WiFi Veil is a reference model, not
    hardware: real-silicon validation (per CLAUDE.md) is future work with a
    captured-log witness.
 
@@ -94,8 +95,8 @@ Per repository policy, every quantitative claim is tagged:
 - **MEASURED** — from a cited primary source with its metric and conditions.
 - **CLAIMED** — asserted by a source (vendor PR, press, standards minutes)
   without an independent measurement.
-- **SYNTHETIC** — produced by VEIL's own deterministic model; reproduced by
+- **SYNTHETIC** — produced by WiFi Veil's own deterministic model; reproduced by
   `cargo test`, describing the model and not real hardware.
 
-WiFi sensing is never presented here as camera-grade, and no VEIL result implies
+WiFi sensing is never presented here as camera-grade, and no WiFi Veil result implies
 a defense guarantee on real silicon until a hardware witness exists.