chore(db): resync stale EF ModelSnapshot + fix fresh-DB schema gap

Backlog item 1. The committed ModelSnapshot was empty/stale (21 lines, no
entities) -- `dotnet ef migrations add` scaffolded the whole database from
scratch against it, including the ASP.NET Identity tables, which have never
been created by a real EF migration in this repo (always provisioned via the
raw-SQL reconciler in StartupInitializationExtensions.cs -- see
EnsureIdentityTables' own comment). Applying that diff for real would throw
"table/column already exists" on every environment.

Fix: added migration 20260711181039_SyncModelSnapshot with an intentionally
empty Up()/Down() (see its doc comment) -- it only records itself in
__EFMigrationsHistory and regenerates the snapshot to match the live model,
so `dotnet ef migrations add` produces a real diff for the next schema
change instead of the whole database again. Verified zero side effects
against a copy of the dev DB (only inserts one history row) and against a
fresh empty DB (full migration + reconciler chain runs clean).

That fresh-DB verification surfaced a real, previously-undiscovered bug:
EnsureColumn/EnsureMySqlColumn calls for JobApplications/Correspondences/
Companies/Attachments ad-hoc columns all no-op on a truly fresh database
(the tables don't exist yet -- Migrate() creates them afterward), so a
brand-new deployment's first boot would be missing dozens of columns
(LastReminderEmailSentAt, RecruiterMessageDraft, salary fields, Correspondence
Provider/Subject/Channel/etc.) until the next restart. Also caught: my own b4
change (Correspondence.Provider backfill, already merged) had the same
unguarded-on-fresh-DB bug in isolation.

Fixed by promoting the schema-reconciliation helpers (Exec/HasTable/
HasColumn/EnsureColumn and their MySQL equivalents) from local functions to
class-level statics, extracting the ad-hoc-column blocks into
ReconcileCoreAppColumns/ReconcileCoreAppColumnsMySql, and calling them a
second time right after Migrate() succeeds (reusing the connection already
opened for the CoreSchemaReady check) -- idempotent, so free on every boot
except the first one, where it's now required. No inline logic changed,
pure extraction + one additional call site.

Also added Microsoft.EntityFrameworkCore.Design to JobTrackerApi.csproj
(dotnet-ef tooling requires it on the startup project since EF Core 6+;
previously only referenced by JobTrackerBackend, where the DbContext lives).

169/169 backend tests green. Verified live: full app boot against both a
fresh empty SQLite DB and a copy of the populated dev DB, both clean.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

JobTrackerApi/Migrations/20260711181039_SyncModelSnapshot.cs

@@ -0,0 +1,33 @@
+using System;
+using Microsoft.EntityFrameworkCore.Migrations;
+
+#nullable disable
+
+namespace JobTrackerApi.Migrations
+{
+    /// <summary>
+    /// Intentionally a no-op. The committed ModelSnapshot had drifted far behind the live schema
+    /// (empty -- see JobTrackerContextModelSnapshot.cs history): every table/column added since
+    /// the last real migration (2026-03-11) was provisioned exclusively through the idempotent
+    /// raw-SQL reconciler in StartupInitializationExtensions.cs, including the ASP.NET Identity
+    /// tables themselves, which have never been created by an EF migration in this repo -- see
+    /// EnsureIdentityTables' comment ("create Identity tables directly if dotnet ef isn't
+    /// available"). `dotnet ef migrations add` scaffolded the honest diff against that stale
+    /// snapshot: full CreateTable/AddColumn operations for schema that already exists on every
+    /// environment (fresh or established) via that reconciler. Applying that diff for real would
+    /// throw "table/column already exists" everywhere. This migration exists only to record itself
+    /// in __EFMigrationsHistory and regenerate JobTrackerContextModelSnapshot.cs to match the
+    /// current C# model, so `dotnet ef migrations add` produces a real (small) diff for the *next*
+    /// schema change instead of scaffolding the whole database again. It changes no data or schema.
+    /// </summary>
+    public partial class SyncModelSnapshot : Migration
+    {
+        protected override void Up(MigrationBuilder migrationBuilder)
+        {
+        }
+
+        protected override void Down(MigrationBuilder migrationBuilder)
+        {
+        }
+    }
+}