[Blocker] Move EF Core migrations out of application startup

Tier 1 — release blocker

Problem

Database.MigrateAsync() runs on every boot inside Program.cs and rethrows on failure, so a bad migration or a cold/throttled SQL connection takes the whole site down at startup. With more than one instance, migrations race against each other. This has already caused an Azure startup failure (commit 06b8f0a, "fix: add missing user display name migration").

Evidence

• LearnStack/Program.cs:57-70

Proposed fix

1. Generate a migration bundle in CI: dotnet ef migrations bundle --self-contained.
2. Run the bundle as a deployment step against the target database, before the app is swapped in.
3. Keep startup read-only — at most a CanConnectAsync check wired into the health endpoint.
4. Optionally guard with a pending-migration check that fails the health probe rather than the process.

Acceptance criteria

• App startup performs no schema changes
• Deploy pipeline applies migrations as an explicit, observable step
• A failed migration blocks the swap instead of crashing production

Start with LearnStack/Program.cs:57-70 and trace the current Database.MigrateAsync() startup path. Review how the deployment pipeline can run dotnet ef migrations bundle --self-contained before swap and how the health endpoint should report connectivity or pending migrations. Done means startup performs no schema changes, deployment applies migrations observably, and failures block the swap rather than crash the app.