chore(docs+devops): cross-module doc sync + sprint archival moves + compose updates

Bundled pre-session doc + ops work:
- docs/modules/**: sync across advisory-ai, airgap, cli, excititor,
  export-center, findings-ledger, notifier, notify, platform, router,
  sbom-service, ui, web (architectural + operational updates)
- docs/features/**: updates to checked excititor vex pipeline,
  developer workspace, quick verify drawer
- docs top-level: README, quickstart, API_CLI_REFERENCE, UI_GUIDE,
  code-of-conduct/TESTING_PRACTICES updates
- docs/qa/feature-checks/: FLOW.md + excititor state update
- docs/implplan/: remaining sprint updates + new Concelier source
  credentials sprint (SPRINT_20260422_003)
- docs-archived/implplan/: 30 sprint archival moves (ElkSharp series,
  misc completed sprints)
- devops/compose: .env + services compose + env example + router gateway
  config updates

File-level granularity preserved.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/qa/feature-checks/FLOW.md

@@ -178,7 +178,8 @@ the described behavior.
 2. Run `dotnet build <project>.csproj` and capture output
 3. Run the targeted tests and confirm the filter actually executes the intended subset.
    - For VSTest-style projects where filtering works normally, use `dotnet test <test-project>.csproj --filter <relevant-filter>`.
-   - For xUnit v3 projects running under Microsoft Testing Platform, do **not** rely on `dotnet test --filter`; use `scripts/test-targeted-xunit.ps1` or direct `dotnet exec <test-dll> -method/-class/...` instead.
+   - For xUnit v3 projects running under Microsoft Testing Platform, do **not** rely on `dotnet test --filter`; use `scripts/test-targeted-xunit.ps1` instead. Invoke the helper with `pwsh` on PowerShell 7 hosts or `powershell -ExecutionPolicy Bypass -File` on Windows PowerShell hosts.
+   - The helper auto-selects `dotnet exec <test-dll>` for standard library-style assemblies and `dotnet run --project <test-project> -- ...` for ASP.NET host tests that reference `Microsoft.AspNetCore.Mvc.Testing`. If you bypass the helper, preserve that same distinction.
 4. For Angular/frontend features: run `npx ng build` and `npx ng test` for the relevant library/app
 5. **Code review** (CRITICAL): Read the key source files and verify:
    - The classes/methods described in the feature file actually contain the logic claimed
@@ -368,14 +369,14 @@ integration tests** or **behavioral unit tests** that prove the feature logic:
 1. Identify tests that specifically exercise the feature's behavior
 2. Run those tests using a targeting path that actually filters the assembly:
    - VSTest-compatible path: `dotnet test <test-project>.csproj --filter "FullyQualifiedName~FeatureClassName"`
-   - xUnit v3 / Microsoft Testing Platform path: `pwsh ./scripts/test-targeted-xunit.ps1 -Project <test-project>.csproj -Class "<fully.qualified.class>"`
+   - xUnit v3 / Microsoft Testing Platform path: `pwsh ./scripts/test-targeted-xunit.ps1 -Project <test-project>.csproj -Class "<fully.qualified.class>"` or `powershell -ExecutionPolicy Bypass -File .\scripts\test-targeted-xunit.ps1 -Project <test-project>.csproj -Class "<fully.qualified.class>"`
 3. Read the test code to confirm it asserts meaningful behavior (not just "compiles")
 4. If no behavioral tests exist, write a focused test and run it
 
 **Example for `evidence-weighted-score-model`**:
-```bash
-pwsh ./scripts/test-targeted-xunit.ps1 \
-  -Project src/Policy/__Tests/StellaOps.Policy.Engine.Tests/StellaOps.Policy.Engine.Tests.csproj \
+```powershell
+powershell -ExecutionPolicy Bypass -File .\scripts\test-targeted-xunit.ps1 `
+  -Project src/Policy/__Tests/StellaOps.Policy.Engine.Tests/StellaOps.Policy.Engine.Tests.csproj `
   -Class "StellaOps.Policy.Engine.Tests.Scoring.EwsCalculatorTests"
 # Verify: normalizers produce expected dimension scores
 # Verify: guardrails cap/floor scores correctly