Base provisioning: static ref-data into schema + secure first-run admin (generated secret + MustChangePassword) — retire Seed:* config #283

Owner idea from the #280 discussion. Follow-on to #280 (which moves Demo/Simulation seeding off the boot path into a command but leaves the base DatabaseSeeder as-is). This issue reworks the base provisioning so a fresh deploy is usable with no Seed:* config and no publicly-known credential.

Goal

Retire the runtime base DatabaseSeeder + the Seed:Enabled/Seed:AdminEmail/Seed:AdminPassword config surface. A fresh, migrated database should come up already usable, and the first admin should be forced to set their own password — without ever shipping a known credential.

Two clearly-separable parts

1. Static reference data → into the schema (low risk, clear win)

Roles (Admin/Manager/Sales/ReadOnly), the 10 default egg grades, and the default account are static reference data. Move them into the InitialCreate migration via migrationBuilder.InsertData(...) (or a dedicated data migration). No runtime seeder, no config, deterministic, multi-instance-safe by construction.

2. First admin → secure first-run, NOT a baked-in credential (the careful part)

A user row needs a password hash, so baking an admin into the migration means every deployment ships the same publicly-known admin credential (the hash is in the OSS repo). "Force a change on first login" fixes the post-first-login state but leaves the deploy→first-login window exposed with a repo-known password — a regression vs today's operator-supplied secret for the internet-facing prod #244 targets. So do NOT hardcode a credential. Options (decide during design):

• Generated-at-first-run secret: on first boot against an un-provisioned DB, generate a random admin password, create the admin, and surface it once to the operator (container log line and/or a one-time setup token/URL) — the pattern GitLab/Grafana/etc. use. Nothing known ever ships.
• MustChangePassword on top: a domain flag on the admin user, an auth gate that forces a password change before any other action, and a first-login "set your password" screen in the SPA. New surface: domain (User.MustChangePassword), the login/refresh flow, and a SPA screen.
• Keep an operator-supplied override (env) for those who prefer to inject their own admin secret.

Blast radius / pieces

• EF migration with InsertData for roles/grades/account (+ a SecurityReviewed check that no credential/hash is embedded).
• A first-run admin bootstrap (generate + surface secret) — as a one-shot command sibling of Extract DB seeding (Demo/Simulation) out of API startup into an explicit command entry point #280's seed/migrate, NOT a serving-boot side effect.
• MustChangePassword: domain flag + auth gate + SPA first-login password screen (+ Vitest).
• Retire Seed:Enabled/AdminEmail/AdminPassword; update deploy/.env(.example), compose, and docs; the integration-test helpers that currently create accounts directly are unaffected.
• Ships with the standing rule: every user-visible change updates GLOSSARY.md + the SPA Help page.

Why its own issue (not #280)

#280 moves the seed invocation; this changes what the base data is and how the first admin is secured — with real security (#244) + auth-flow + SPA-UX implications. It deserves a design pass (likely a brainstorm on the first-run-secret mechanism) before implementation.

Refs

• Extract DB seeding (Demo/Simulation) out of API startup into an explicit command entry point #280 (moves Demo/Sim seeding to a command; leaves base seeder — this replaces it), Deployment readiness audit: production go-live scan before first real users (host undecided) #244 (deployment-readiness / prod credential story), Squash the 30 EF migrations into a single InitialCreate before first production deploy #245 (MigrateOnStartup + one-shot init posture), F12: Demo seed data — Seed:Demo flag for dev/demo environments #58 (demo data), F18: In-app help — user guide + glossary in the SPA #71 (Help page), Tech debt: magic strings — duplicated role/claim constants, untyped SPA status strings #84 (magic-strings/config surface).

Post-login privilege boundary — 2026-07-31

This issue secures first provisioning and forced first-password change. It does not address a stolen, already-authenticated Owner token creating a durable replacement Owner or resetting another privileged password. Recent step-up authentication for those post-login operations is tracked separately in #308.

• Keep first-run setup tokens/passwords and browser step-up grants as separate credential types, audiences, lifetimes, and revocation paths.
• Do not close Require recent step-up authentication for privileged user administration #308 as covered by MustChangePassword or generated first-run credentials.