docs: module dossier + install/quickstart sync for truthful cutover sprints

- API_CLI_REFERENCE.md, INSTALL_GUIDE.md, quickstart.md, architecture/integrations.md, dev/DEV_ENVIRONMENT_SETUP.md, integrations/LOCAL_SERVICES.md: reflect real-service wiring.
- docs/modules/**: module dossier updates across the modules touched by SPRINT_20260415_001..007 + SPRINT_20260416_003..017 + SPRINT_20260417_018..024 + SPRINT_20260418_025 + SPRINT_20260419_026.
- docs/features/checked/web/**: update feature notes where UI changed.
- docs/qa/feature-checks/runs/web/evidence-presentation-ux/: QA evidence artifacts.
- docs/setup/**, docs/technical/**: align with setup wizard contracts.

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

docs/modules/scanner/architecture.md

@@ -236,6 +236,8 @@ See docs/modules/scanner/byos-ingestion.md for BYOS workflow, formats, and troub
   - `GET /api/v1/scans/{id}/manifest`
   - `GET /api/v1/scans/{id}/proofs`
   - `GET /api/v1/scans/{id}/proofs/{rootHash}`
+- SBOM upload records are durable runtime state and are stored in PostgreSQL table `scanner.sbom_uploads`; the WebService must not rebind this path to an in-memory upload store.
+- Policy snapshot and policy audit state are durable runtime state and are stored through the Policy PostgreSQL backend; the WebService must not rebind these paths to in-memory policy repositories.
 - The live manifest/proof and score-replay retrieval path is backed by PostgreSQL tables `scanner.scan_manifest` and `scanner.proof_bundle`.
 - `StellaOps.Scanner.WebService` must not bind these runtime paths to `InMemoryScanManifestRepository`, `InMemoryProofBundleRepository`, `TestManifestRepository`, or `TestProofBundleRepository`.
 - When singleton replay services need manifest/proof access, they must resolve the scoped PostgreSQL repositories through an adapter rather than bypassing persisted storage.
@@ -408,6 +410,8 @@ When an SBOM path is provided, the worker runs the `service-security` stage to p
 
 Inputs are passed via scan metadata (`sbom.path` or `sbomPath`, plus `sbom.format`). The report is attached as a surface observation payload (`service-security.report`) and keyed in the analysis store for downstream policy and report assembly. See `src/Scanner/docs/service-security.md` for the policy schema and output formats.
 
+Runtime reconciliation and downstream policy helpers now resolve scan metadata from persisted scan manifests rather than a standalone in-memory metadata store. This keeps metadata derivation restart-safe as long as the canonical manifest record exists.
+
 ### 5.5.2 CBOM crypto analysis (Sprint 20260119_017)
 
 When an SBOM includes CycloneDX `cryptoProperties`, the worker runs the `crypto-analysis` stage to produce a crypto inventory and compliance findings for weak algorithms, short keys, deprecated protocol versions, certificate hygiene, and post-quantum readiness. The report is attached as a surface observation payload (`crypto-analysis.report`) and keyed in the analysis store for downstream evidence workflows. See `src/Scanner/docs/crypto-analysis.md` for the policy schema and inventory export formats.
@@ -439,6 +443,8 @@ Scanner now exposes a deterministic VEX+reachability matrix filter for triage pr
 - API surface: `POST /api/v1/scans/vex-reachability/filter` accepts finding batches and returns annotated decisions plus action summary counts.
 - Determinism: batch order is preserved, rule IDs are explicit, and no network lookups are required for matrix evaluation.
 
+The read-side VEX gate endpoints (`GET /api/v1/scans/{scanId}/gate-results`, `/gate-summary`, and `/blocked-findings`) no longer bind to a canonical in-memory store in live runtime. Until Scanner grows a durable VEX gate results backend, those endpoints return `501 Not Implemented` with `error = "vex_gate_results_unsupported"` instead of inventing transient state.
+
 ### 5.5.7 Vulnerability-first triage clustering APIs (Sprint 20260208_063)
 
 Scanner triage now includes deterministic exploit-path clustering primitives for vulnerability-first triage workflows:
@@ -694,6 +700,7 @@ ResolveEntrypoint(ImageConfig cfg, RootFs fs):
 - Reachability graphs/traces are folded into the manifest via `ReachabilityReplayWriter`; manifests and bundles hash with stable ordering for replay verification (`docs/replay/DETERMINISTIC_REPLAY.md`).
 - Worker sealed-mode intake reads `replay.bundle.uri` + `replay.bundle.sha256` (plus determinism feed/policy pins) from job metadata, persists bundle refs in analysis and surface manifest, and validates hashes before use.
 - Deterministic execution switches (`docs/modules/scanner/deterministic-execution.md`) must be enabled when generating replay bundles to keep hashes stable.
+- Canonical scan submission/runtime state is durable in PostgreSQL rather than process-local memory: the live host persists scan status, replay bundle attachment, and entropy snapshots in `scanner.scan_runtime_state`, and `PersistedScanCoordinator` is now the authoritative runtime coordinator in `StellaOps.Scanner.WebService`.
 
 EntryTrace emits structured diagnostics and metrics so operators can quickly understand why resolution succeeded or degraded: