[RomainROCH]

What this PR does

Port the passive physical-power validation kit onto main, retaining the current
validation matrix and smoke/build guidance. Add a guide, preparation and checkpoint
scripts, plus mocked preparation checks. The copied guide keeps the filename
PHYSICAL_POWER_VALIDATION.md so its validation-matrix link resolves.

Prepared head: f63a514, branch
test/passive-power-kit-main, original base main1b9556222d89419c5e6b28f2bf83f2d6e0b7d4e1.
Five files changed; Rust source, dependencies and workflows are unchanged.

Why

Physical acceptance remains incomplete. A passive kit provides reproducible case
preparation and checkpoint collection while keeping actual sleep/display,
Hibernate and Modern Standby trials separate. The historical source c2768c1f… and
the newer main validation guidance remain preserved.

How it was tested

• Windows PowerShell5.1 preparation suite: 111 checks passed with every diagnostic
  mocked. No real powercfg, event query, runtime or Power Request was used.

• Docs: 27 Markdown files passed; local anchors are not validated.

• Developer tooling: the original long-path run failed because WinPS5.1 wrapped
  the expected fake-Cargo exit7 message. A byte-identical short-path fixture passed;
  the original failure and logs remain preserved.

• Smoke safety passed with seven fake preflight fixtures and cleanup callbacks.

• One evidence wrapper exited1 after mixing progress text and numeric status;
  independent verification confirms native children exit0, pass sentinels, empty
  stderr, unchanged source hashes and temporary cleanup. Original receipts remain.

• Recovery bundle/head/tree and fsck strict passed; private content/identity and
  secret scanner gates passed on the committed lot and named receipts.

• Docs checks pass; no Rust change requiring a local Full run.

• Developer tooling fixtures assessed as described above.

• Smoke safety fixtures pass.

• Runtime/physical/manual checks skipped and limits explained.

• Validation guide and matrix updated.

Checklist

• Main is the explicitly requested integration target. Integrate after the
  distinct status fix has cleared its authorized merge and exact-main checks.
• No architecture or runtime contract change.
• No business-model change.

The kit's mocked checks do not qualify a new binary for physical power behavior.
Future real diagnostic captures may contain other application names and paths;
keep them local and review/redact before sharing.