Add unit and integration tests for VexCandidateEmitter and SmartDiff repositories

- Implemented comprehensive unit tests for VexCandidateEmitter to validate candidate emission logic based on various scenarios including absent and present APIs, confidence thresholds, and rate limiting.
- Added integration tests for SmartDiff PostgreSQL repositories, covering snapshot storage and retrieval, candidate storage, and material risk change handling.
- Ensured tests validate correct behavior for storing, retrieving, and querying snapshots and candidates, including edge cases and expected outcomes.

src/Scheduler/__Libraries/StellaOps.Scheduler.Models/docs/SCHED-MODELS-16-103-DESIGN.md

@@ -2,7 +2,7 @@
 
 ## Goals
 - Track schema revisions for `Schedule` and `Run` documents so storage upgrades are deterministic across air-gapped installs.
-- Provide reusable upgrade helpers that normalize Mongo snapshots (raw BSON → JSON) into the latest DTOs without mutating inputs.
+- Provide reusable upgrade helpers that normalize PostgreSQL snapshots (raw JSONB → JSON) into the latest DTOs without mutating inputs.
 - Formalize the allowed `RunState` graph and surface guard-rail helpers (timestamps, stats monotonicity) for planners/runners.
 
 ## Non-goals
@@ -17,7 +17,7 @@
   - `scheduler.impact-set@1` (shared envelope used by planners).
 - Expose `EnsureSchedule`, `EnsureRun`, `EnsureImpactSet` helpers mirroring the Notify model pattern to normalize missing/whitespace values.
 - Extend `Schedule`, `Run`, and `ImpactSet` records with an optional `schemaVersion` constructor parameter defaulting through the `Ensure*` helpers. The canonical JSON serializer will list `schemaVersion` first so documents round-trip deterministically.
-- Persisted Mongo documents will now always include `schemaVersion`; exporters/backups can rely on this when bundling Offline Kit snapshots.
+- Persisted PostgreSQL documents will now always include `schemaVersion`; exporters/backups can rely on this when bundling Offline Kit snapshots.
 
 ## Migration Helper Shape
 - Add `SchedulerSchemaMigration` static class with:
@@ -55,8 +55,8 @@
 - Expose small helper to tag `RunReason.ImpactWindowFrom/To` automatically when set by planners (using normalized ISO-8601).
 
 ## Interaction Points
-- **WebService**: call `SchedulerSchemaMigration.UpgradeSchedule` when returning schedules from Mongo, so clients always see the newest DTO regardless of stored version.
-- **Storage.Mongo**: wrap DTO round-trips; the migration helper acts during read, and the state machine ensures updates respect transition rules before writing.
+- **WebService**: call `SchedulerSchemaMigration.UpgradeSchedule` when returning schedules from PostgreSQL, so clients always see the newest DTO regardless of stored version.
+- **Storage.Postgres**: wrap DTO round-trips; the migration helper acts during read, and the state machine ensures updates respect transition rules before writing.
 - **Queue/Worker**: use `RunStateMachine.EnsureTransition` to guard planner/runner state updates (replace ad-hoc `with run` clones).
 - **Offline Kit**: embed `schemaVersion` in exported JSON/Trivy artifacts; migrations ensure air-gapped upgrades flow without manual scripts.
 
@@ -67,20 +67,20 @@
 4. Update modules (Storage, WebService, Worker) to use new helpers; add logging around migrations/transitions.
 
 ## Test Strategy
-- **Migration happy-path**: load sample Mongo fixtures for `schedule@1` and `run@1`, assert `schemaVersion` normalization, deduplicated subscribers, limits defaults. Include snapshots without the version field to exercise defaulting logic.
+- **Migration happy-path**: load sample PostgreSQL fixtures for `schedule@1` and `run@1`, assert `schemaVersion` normalization, deduplicated subscribers, limits defaults. Include snapshots without the version field to exercise defaulting logic.
 - **Legacy upgrade cases**: craft synthetic `schedule@0` / `run@0` JSON fragments (missing new fields, using old enum names) and verify version-specific fixups produce the latest DTO while populating `MigrationResult.Warnings`.
 - **Strict mode behavior**: attempt to upgrade documents with unexpected properties and ensure warnings/throws align with configuration.
 - **Run state transitions**: unit-test `RunStateMachine` for every allowed edge, invalid transitions, and timestamp/error invariants (e.g., `FinishedAt` only set on terminal states). Provide parameterized tests to confirm stats monotonicity enforcement.
 - **Serialization determinism**: round-trip upgraded DTOs via `CanonicalJsonSerializer` to confirm property order includes `schemaVersion` first and produces stable hashes.
 - **Documentation snippets**: extend module README or API docs with example migrations/run-state usage; verify via doc samples test (if available) or include as part of CI doc linting.
 
-## Open Questions
-- Do we need downgrade (`ToVersion`) helpers for Offline Kit exports? (Assumed no for now. Add backlog item if required.)
-- Should `ImpactSet` migrations live here or in ImpactIndex module? (Lean towards here because DTO defined in Models; coordinate with ImpactIndex guild if they need specialized upgrades.)
-- How do we surface migration warnings to telemetry? Proposal: caller logs `warning` with `MigrationResult.Warnings` immediately after calling helper.
-
-## Status — 2025-10-20
-
-- `SchedulerSchemaMigration` now upgrades legacy `@0` schedule/run/impact-set documents to the `@1` schema, defaulting missing counters/arrays and normalizing booleans & severities. Each backfill emits a warning so storage/web callers can log the mutation.
-- `RunStateMachine.EnsureTransition` guards timestamp ordering and stats monotonicity; builders and extension helpers are wired into the scheduler worker/web service plans.
-- Tests exercising legacy upgrades live in `StellaOps.Scheduler.Models.Tests/SchedulerSchemaMigrationTests.cs`; add new fixtures there when introducing additional schema versions.
+## Open Questions
+- Do we need downgrade (`ToVersion`) helpers for Offline Kit exports? (Assumed no for now. Add backlog item if required.)
+- Should `ImpactSet` migrations live here or in ImpactIndex module? (Lean towards here because DTO defined in Models; coordinate with ImpactIndex guild if they need specialized upgrades.)
+- How do we surface migration warnings to telemetry? Proposal: caller logs `warning` with `MigrationResult.Warnings` immediately after calling helper.
+
+## Status — 2025-10-20
+
+- `SchedulerSchemaMigration` now upgrades legacy `@0` schedule/run/impact-set documents to the `@1` schema, defaulting missing counters/arrays and normalizing booleans & severities. Each backfill emits a warning so storage/web callers can log the mutation.
+- `RunStateMachine.EnsureTransition` guards timestamp ordering and stats monotonicity; builders and extension helpers are wired into the scheduler worker/web service plans.
+- Tests exercising legacy upgrades live in `StellaOps.Scheduler.Models.Tests/SchedulerSchemaMigrationTests.cs`; add new fixtures there when introducing additional schema versions.

src/Scheduler/__Libraries/StellaOps.Scheduler.Worker/docs/SCHED-WORKER-16-201-PLANNER.md

@@ -15,7 +15,7 @@ surface) so we can operate across tenants without bespoke cursors.
 - Delegates resolution to `PlannerExecutionService` which:
   - Pulls the owning `Schedule` and normalises its selector to the run tenant.
   - Invokes `IImpactTargetingService` to resolve impacted digests.
-  - Emits canonical `ImpactSet` snapshots to Mongo for reuse/debugging.
+  - Emits canonical `ImpactSet` snapshots to PostgreSQL for reuse/debugging.
   - Updates run stats/state and projects summaries via `IRunSummaryService`.
   - Enqueues a deterministic `PlannerQueueMessage` to the planner queue when
  impacted images exist; otherwise the run completes immediately.

src/Scheduler/__Libraries/StellaOps.Scheduler.Worker/docs/SCHED-WORKER-16-203-RUNNER.md

@@ -49,6 +49,6 @@ exponential backoff.
 
 - `AddSchedulerWorker(configuration)` registers impact targeting, planner
   dispatch, runner execution, and the three hosted services. Call it after
-  `AddSchedulerQueues` and `AddSchedulerMongoStorage` when bootstrapping the
+  `AddSchedulerQueues` and `AddSchedulerPostgresStorage` when bootstrapping the
   worker host.
 - Extend execution metrics (Sprint 16-205) before exposing Prometheus counters.

src/Scheduler/__Libraries/StellaOps.Scheduler.Worker/docs/SCHED-WORKER-20-301-POLICY-RUNS.md

@@ -3,7 +3,7 @@
 _Sprint 20 · Scheduler Worker Guild_
 
 This milestone introduces the worker-side plumbing required to trigger Policy Engine
-runs from scheduler-managed jobs. The worker now leases policy run jobs from Mongo,
+runs from scheduler-managed jobs. The worker now leases policy run jobs from PostgreSQL,
 submits them to the Policy Engine REST API, and tracks submission state deterministically.
 
 ## Highlights
@@ -11,8 +11,8 @@ submits them to the Policy Engine REST API, and tracks submission state determin
 - New `PolicyRunJob` DTO (stored in `policy_jobs`) captures run metadata, attempts,
   lease ownership, and cancellation markers. Schema version `scheduler.policy-run-job@1`
   added to `SchedulerSchemaVersions` with canonical serializer coverage.
-- Mongo storage gains `policy_jobs` collection with indexes on `{tenantId, status, availableAt}`
-  and `runId` uniqueness for idempotency. Repository `IPolicyRunJobRepository` exposes
+- PostgreSQL storage gains `policy_jobs` table with indexes on `(tenant_id, status, available_at)`
+  and `run_id` uniqueness for idempotency. Repository `IPolicyRunJobRepository` exposes
   leasing and replace semantics guarded by lease owner checks.
 - Worker options now include `Policy` dispatch/API subsections covering lease cadence,
   retry backoff, idempotency headers, and base URL validation.

src/Scheduler/__Libraries/StellaOps.Scheduler.Worker/docs/SCHED-WORKER-21-201-GRAPH-BUILD.md

@@ -2,7 +2,7 @@
 
 _Sprint 21 · Scheduler Worker Guild_
 
-The graph build worker leases pending `GraphBuildJob` records from Mongo, invokes
+The graph build worker leases pending `GraphBuildJob` records from PostgreSQL, invokes
 Cartographer to construct graph snapshots, and records terminal status via the
 Scheduler WebService webhook so downstream systems observe completion events.