refactor(db): adopt email settings migration

docs/audits/audit-remediation-backlog.md

@@ -558,6 +558,8 @@ SEC-008 implements the same durable state machine with `<final>.uploading` and `
 
 ### P3-1 — Reduce dual schema ownership incrementally
 
+**Status (2026-08-30): in progress.** All 49 model tables now have an executable, disjoint creation-owner classification. `SystemEmailSettings` is the first completed transfer: additive provider-aware migration, legacy-row preservation, startup-DDL removal, fresh SQLite runtime proof, generated MariaDB SQL, and backend 722/722. Thirty-four startup-created tables remain; see `docs/verification/jt-019-schema-ownership.md` and V-194.
+
 - **Findings/scope:** JT-019; inventory reconciler operations and move stable schema ownership to EF migrations in small steps.
 - **Dependencies:** provider upgrade fixtures and P2-2 restore safety.
 - **Acceptance criteria:** every schema mutation has one owner; fresh/upgrade/repair matrices pass on SQLite/MariaDB; startup does no undocumented DDL.

docs/audits/verification-log.md

@@ -225,3 +225,4 @@ Output was reduced to filenames and commit counts. The token artifact appears un
 | V-191 | Real parser child extraction; minimal-environment probe; timeout/process-tree/capacity/stale-cleanup tests; `py_compile`; parser suite; Compose interpolation/control inspection | Repository root / `tools/summarizer` | Ensure untrusted document decode cannot consume the AI web process or inherit provider secrets and receives explicit runtime/container budgets | PASS/PARTIAL — parser 37/37 without warnings; TXT extraction executes in a child; provider/service secrets are absent; timeout kills parent and descendant; capacity recovers; stale cleanup preserves recent/unrelated paths. Compose resolves read-only root, `cap_drop: ALL`, no-new-privileges, 96 PIDs, 2 CPUs, 2 GiB memory, 768 MiB tmpfs and one model-cache volume | Windows proves deadline/process-tree behavior but cannot execute Linux `setrlimit`; Docker Desktop daemon is offline, so image build, non-root identity, inside-container rlimits and benign PDF/DOCX/image sizing remain unverified | SEC-007 repository boundary implemented; Linux/container/browser/production verification remains |
 | V-192 | Exact SDK resolution; generated API/test NuGet locks; locked restore; full backend; transitive NuGet vulnerability audit | Repository root | Make .NET toolchain and transitive package resolution reproducible and fail CI on dependency drift | PASS — SDK 9.0.317 selected by `global.json`; both lock files restore in locked mode; backend 719/719; NuGet reports no known vulnerable direct or transitive package | The first test attempt observed the deliberately started local API holding the apphost, then passed after shutdown; the clean rerun passed without warnings. CI action SHAs, image digests, installer hashing, SBOM and container scanning remain JT-017 work | .NET provenance gap closed; broader build provenance remains partial |
 | V-193 | Clean `npm ci`; lint; focused/full Jest; Next build/TypeScript; locked NuGet restores; full backend; stale-claim/path inspection | Repository root / `job-tracker-ui` | Rebuild current developer/operator documentation and prove its setup, quality and provider claims | PASS — install succeeds without the obsolete peer override; lint zero warnings; CV Builder 12/12 and frontend 64 suites/272 tests; optimized build/TypeScript; locked restores and backend 719/719; every documented path exists | User-local SDK 9.0.317 is shadowed by a runtime-only system host on this workstation, so backend proof invoked the installed host explicitly. No second clean machine or production rehearsal | JT-018 repository documentation complete; external operator rehearsal remains deployment evidence |
+| V-194 | Executable 49-table ownership partition; focused ownership/migration chain; legacy-row upgrade; MariaDB script; full backend; fresh application SQLite startup | Repository root / disposable local SQLite | Establish one creation owner per model table and transfer the independent SystemEmailSettings table from startup DDL to EF migration ownership | PASS — ownership/migration 6/6; blank and repeated migration succeed; representative legacy SMTP row survives; provider SQL is present; backend 722/722; fresh runtime applies `20260830120000_AdoptSystemEmailSettingsSchema` and starts healthy | MariaDB SQL is generated but the new migration was not executed on a live MariaDB server; downgrade deliberately preserves ambiguous pre-migration data. Thirty-four reconciler-owned tables remain | JT-019 first migration-backed ownership transfer complete; provider runtime and remaining dependency groups continue incrementally |

docs/infrastructure/database-ownership.md

@@ -1,6 +1,6 @@
 # Database ownership and startup order
 
-> Updated 2026-08-15. Which component creates which table, in what order, and why a clean MariaDB install used
+> Updated 2026-08-30. Which component creates which table, in what order, and why a clean MariaDB install used
 > to fail. Read this before adding a table or touching `StartupInitializationExtensions`.
 
 ## The problem this document exists to prevent
@@ -16,9 +16,10 @@ A composite index over one of those `TEXT`/`longtext` columns then exceeds MySQL
 limit and startup dies with `Specified key was too long`. This is not theoretical — it crashed
 production once (Phase 4 `CvVariants`) and made every clean MariaDB install fail until 2026-07-19.
 
-**Rule: a table whose migration was scaffolded against SQLite must not be created by that migration
-on MariaDB.** Empty the migration and give the table to the reconciler, which carries correct DDL per
-provider.
+That historical workaround created two schema owners and is now being retired under JT-019. New
+tables belong to migrations. When the generated operation is not provider-safe, hand-author a
+provider-aware migration (using `ActiveProvider`) instead of adding more startup DDL. The reconciler
+is compatibility code for tables and columns that already shipped under its ownership.
 
 ## Startup order
 
@@ -65,10 +66,13 @@ already-correct database. Two consequences worth knowing:
 
 Created by EF migrations, never by the reconciler:
 
-`Companies`, `JobApplications`, `Jobs`, `Correspondences`, `Attachments`, `JobEvents`,
-`RuleSettings`, and the ASP.NET Identity tables. Two compatibility migrations use guarded
-`CREATE TABLE IF NOT EXISTS` bootstraps for `AspNetUsers` and `AiInteractions` so standalone EF
-tooling can traverse the historical chain; normal application startup makes those statements no-ops.
+`AccountDeletionFiles`, `AccountDeletionRequests`, `AiUsageRecords`, `Attachments`, `Companies`,
+`Correspondences`, `EmailDrafts`, `EmailSendAttempts`, `JobApplications`, `JobEvents`, `Jobs`,
+`RuleSettings`, `SystemEmailSettings`, `UserNotifications`, and `UserOperations`.
+
+`SystemEmailSettings` is the first completed ownership transfer: migration
+`20260830120000_AdoptSystemEmailSettingsSchema` creates it for both supported providers and preserves
+an existing reconciler-created MariaDB table. Startup no longer creates it.
 
 The reconciler may **repair** these (add a missing column, add an index, fix a non-`AUTO_INCREMENT`
 primary key) and may seed the default `RuleSettings` row — but it must never `CREATE TABLE` them.
@@ -79,7 +83,7 @@ It used to create `RuleSettings`, which is precisely why a clean install failed
 
 Created by `StartupInitializationExtensions`, with a **no-op migration** holding the model snapshot:
 
-`UserRuleSettings`, `SystemEmailSettings`, `CvUploadArtifacts`, `CvExtractionRuns`,
+`UserRuleSettings`, `CvUploadArtifacts`, `CvExtractionRuns`,
 `GmailConnections`, `MicrosoftGraphConnections`, `ImapConnections`, `TailoredCvDrafts`,
 `CareerProfiles`, `CareerProfileVersions`, the six CareerProfile children (`CareerExperiences`,
 `CareerEducations`, `CareerSkills`, `CareerProjects`, `CareerCertifications`, `CareerLanguages`),
@@ -87,6 +91,14 @@ Created by `StartupInitializationExtensions`, with a **no-op migration** holding
 `ApplicationChecklistItems`, `CoverLetterVersions`, `InterviewPrepItems`, `TwoFactorRecoveryCodes`,
 `TrustedDevices`, `UserSessions`.
 
+The seven ASP.NET Identity tables are also currently reconciler-owned, despite older wording that
+called them migration-owned: `AspNetRoles`, `AspNetUsers`, `AspNetRoleClaims`, `AspNetUserClaims`,
+`AspNetUserLogins`, `AspNetUserRoles`, and `AspNetUserTokens`. Guarded migration bootstraps for
+`AspNetUsers` and `AiInteractions` support standalone traversal but do not yet transfer ownership.
+
+`StartupSchemaOwnership` is the executable inventory. Its tests require every EF model table to
+have exactly one creation owner and keep compatibility bootstraps out of the migration-owned set.
+
 No-op migrations, each with a comment explaining why:
 
 | Migration | Tables |
@@ -119,11 +131,27 @@ as well as index existence — repairing an absent table is not pass 1's job.
 1. Add the entity and its `DbSet`, and **bound every indexed string** with `HasMaxLength` — an
    unbounded string becomes `longtext`, which MariaDB cannot index without a prefix length. This is
    what broke the CareerProfile children.
-2. `dotnet ef migrations add …`, then **empty the `Up`/`Down`** and say why in a comment.
-3. Add SQLite DDL (`CREATE TABLE IF NOT EXISTS`) and MySQL DDL (`int AUTO_INCREMENT`, `varchar(n)`,
-   `datetime(6)`, `tinyint(1)`) to the reconciler. Guard the MySQL create on any parent table.
-4. Create indexes via `EnsureMySqlIndex` / `CREATE INDEX IF NOT EXISTS`.
-5. Verify on a real MariaDB container — see below. EF InMemory will not catch any of this.
+2. Add an EF migration. Review its generated SQL for both SQLite and MariaDB; do not assume a
+   SQLite-scaffolded type is valid on MariaDB.
+3. If needed, replace the generated operation with provider-aware migration SQL (`int
+   AUTO_INCREMENT`, bounded `varchar(n)`, `datetime(6)`, `tinyint(1)` on MariaDB). Do not add the
+   table to `StartupInitializationExtensions`.
+4. Classify the table in `StartupSchemaOwnership.MigrationOwnedTables`; the ownership test will fail
+   if it is omitted or duplicated.
+5. Verify blank, populated-upgrade and restart paths on SQLite and a real MariaDB container. EF
+   InMemory will not catch provider DDL defects.
+
+## Retiring a reconciler-owned table
+
+Move one leaf/dependency group at a time:
+
+1. Add an idempotent provider-aware migration that creates the legacy shape when absent.
+2. Make downgrade preserve a table that may predate migration ownership; never drop ambiguous data.
+3. Remove only that table's startup `CREATE TABLE` block and move it between the executable ownership sets.
+4. Prove a blank database, a pre-migration database with a representative row, migration retry, and
+   provider SQL/runtime behaviour.
+5. Leave column/index repairs in place until historical upgrade fixtures prove they are redundant;
+   table creation and legacy repair are separate ownership decisions.
 
 ## Fresh install
 

docs/verification/jt-019-schema-ownership.md

@@ -0,0 +1,45 @@
+# JT-019 schema ownership — first migration-backed transfer
+
+## Scope
+
+This increment establishes a behaviour-preserving ownership boundary and moves one independent
+table. It does not attempt to delete the legacy reconciler wholesale.
+
+## Implemented
+
+- Added `StartupSchemaOwnership`, classifying all 49 EF model tables into disjoint migration-owned
+  and reconciler-owned creation sets.
+- Added a regression that fails when a model table is unclassified, multiply classified, or when a
+  compatibility bootstrap is incorrectly treated as migration ownership.
+- Added `20260830120000_AdoptSystemEmailSettingsSchema`, with provider-aware additive DDL for SQLite
+  and MariaDB/MySQL.
+- Removed the MariaDB startup `CREATE TABLE` block for `SystemEmailSettings` and moved the table to
+  the migration-owned set.
+- Corrected the ownership runbook: new tables now default to migrations; the reconciler is legacy
+  compatibility code to retire one dependency group at a time.
+
+## Data compatibility
+
+The migration uses `CREATE TABLE IF NOT EXISTS`. Existing MariaDB installations keep their table and
+rows; SQLite installations that never received the reconciler-only table now receive it. `Down` is
+intentionally non-destructive because it cannot determine whether the existing table predates this
+migration.
+
+## Proof
+
+- Ownership and migration-chain focused suite: 6/6 passed.
+- Blank SQLite chain applies all migrations twice and creates all ten expected
+  `SystemEmailSettings` columns.
+- A database stopped immediately before the adoption migration, seeded with a representative SMTP
+  settings row, upgrades without changing that row.
+- Generated MariaDB SQL contains the provider-correct `SystemEmailSettings` DDL.
+- Full backend: 722/722 passed.
+- Fresh application startup over a new disposable SQLite database applied
+  `20260830120000_AdoptSystemEmailSettingsSchema` and reached the healthy listening state.
+
+## Remaining JT-019 work
+
+Thirty-four model tables remain startup-created, including the Identity group and several tables
+with parent dependencies. Transfer them in small dependency-aware migrations with blank, populated,
+retry and MariaDB runtime proof. Column/index repairs must remain until historical upgrade fixtures
+prove each one redundant.

docs/work-programmes/master-progress.md

@@ -43,6 +43,7 @@ Updated: 2026-08-30
 - Restored the local Python 3.12 toolchain and both virtual environments; the AI sidecar now passes 26/26 tests. Added a Next.js-compatible ESLint 9 flat configuration, strict zero-warning scripts, and a patched CommonJS-compatible `brace-expansion` override. The lint gate passes with zero findings and npm audit reports zero vulnerabilities.
 - Pinned the repository to .NET SDK 9.0.317, generated content-hashed transitive NuGet locks for the API and test project, and made CI restores fail on lock drift. Locked restore and backend 719/719 pass; the current NuGet graph has no known vulnerable packages.
 - Rebuilt the active developer/operator documentation around the actual Next.js 16/.NET 9 application, replaced CRA and `npm start` guidance, separated normal and Playwright ports, corrected React Router 7 and the SQLite/MariaDB provider matrix, removed the obsolete npm peer override, and verified the documented clean install, lint, test, build and locked-restore commands.
+- Began the JT-019 schema-ownership retirement with an executable 49-table ownership partition and transferred the leaf `SystemEmailSettings` table from MariaDB-only startup DDL to an additive provider-aware migration. Fresh SQLite now receives the table; legacy rows are preserved and startup no longer creates it.
 
 ### In progress
 
@@ -120,7 +121,7 @@ Updated: 2026-08-30
 - **Deferred work:** None. Conditional multi-replica coordination, model deletion, realtime operation delivery and unrelated production changes remain outside current packages.
 - **Immediate order:** all sixteen immediate repository items are complete locally, including the original UI/release queue plus SEC-009 cache/tombstone safety, worker restart clocks, universal AI accounting, email-token/Stripe lifecycle tests, exhaustive Job email selectors, the repaired migration chain, CV/public-edge hardening and measured admin/mail scaling. PROD-001 read-only evidence and the PROD-003 plan-only harness are also complete. The final audit is checking tooling/documentation before declaring only external blockers remain.
 - **Status counts:** 8 `VERIFIED LOCALLY`; 27 `IMPLEMENTED — NOT VERIFIED`; 0 `IN PROGRESS`; 0 `NOT STARTED`; 4 `BLOCKED`; 0 `DONE`; 0 `DEFERRED`.
-- **Test status:** backend 719/719; frontend 64/64 suites and 272/272 tests; ESLint zero findings; AI sidecar 37/37 without warnings; Ollama benchmark harness 5/5 plus safe dry-run; optimized production build/TypeScript; EF model parity; SQLite/MariaDB migration scripts; blank/idempotent/populated SQLite migration-chain tests; disposable fresh/restarted MariaDB 11.8 application startup; Docker Compose config; safe-failure deployment preflight; and Playwright 9/9. npm audit remains at zero. The parser image build is pending because Docker Desktop's daemon is offline. Jest's slow/open-handle behavior remains recorded.
+- **Test status:** backend 722/722; frontend 64/64 suites and 272/272 tests; ESLint zero findings; AI sidecar 37/37 without warnings; Ollama benchmark harness 5/5 plus safe dry-run; optimized production build/TypeScript; EF model parity; SQLite/MariaDB migration scripts; blank/idempotent/populated SQLite migration-chain tests; fresh SQLite application startup through the SystemEmailSettings ownership migration; disposable fresh/restarted MariaDB 11.8 application startup; Docker Compose config; safe-failure deployment preflight; and Playwright 9/9. npm audit remains at zero. The new ownership migration has generated MariaDB SQL but still needs a MariaDB runtime rehearsal; the parser image build is pending because Docker Desktop's daemon is offline. Jest's slow/open-handle behavior remains recorded.
 - **Deployment status:** Gitea pull-request run 609 passed the complete CI job in 4m20s. Deploy was intentionally skipped because the workflow deploys only a `push` to `main`; live remains unchanged. No merge/deployment was performed directly, no production migrations were run and the AI operation worker remains disabled by default.
 - **Production status:** State unchanged. Sanitized read-only SSH inventory was performed; no logs, prompts, private rows/content or secret values were read, and no provider/model call, model pull, service restart, file/config change, backup, restore, migration or deployment occurred. It confirmed all-interface Ollama/frontend listeners and stale database-only backups as rollout blockers.
 - **Known regressions:** None found by automated/local browser checks. Jest still needs `--forceExit` and reports its existing open-handle notice. Email-provider/send tests are fake/local only; real delivery is not claimed. Current MAIL browser evidence is 1280×720 only because the browser surface could not resize or perform native Tab traversal. Interrupted attempts are aged after 15 minutes and notified without retry; the five-minute scan is unmeasured on a large ledger. The direct clean EF-only SQLite defect and synchronous AI accounting gap are closed; migration/reconciler dual ownership remains architectural debt.