feat: Phase 0 foundation — Job entity, expanded pipeline, AI service lockdown, DateApplied history

Unblocks the documented core workflow and closes the AI-service exposure,
without changing existing behaviour.

Job/JobApplication split (additive; see ADR-002):
- New Job entity (the opportunity) with owner-scoped query filter; nullable
  JobApplication.JobId FK. Nothing reads Job yet.
- Migration AddJobEntityAndProspectStages, hand-edited to drop reconciler-owned
  tables the scaffolder re-emitted; verified against the real dev DB.

Pipeline: 10 internal stages across three concerns kept separate —
PipelineStage (workflow) / PipelineGroup (UI: NotApplied/Active/Closed) /
PipelineCategory (analytics). Adds Saved/Interested/Preparing/Withdrawn;
keeps Waiting and Ghosted. Kanban shows 3 grouped columns; cards keep a stage
chip and full transitions; drag applies only safe transitions (never infers
Ghosted/Withdrawn).

DateApplied nullable + SavedAt. Cleared when leaving Applied so analytics stay
accurate; the discarded date is preserved as an AppliedDateCleared JobEvent.

AI service lockdown: no host port; private ai_internal network (backend is the
only other member); X-Ai-Service-Token required on all non-/health endpoints;
AI_SERVICE_TOKEN mandatory via compose. Verified backend-only against the live
stack.

Also carries two pre-existing working-tree files (views/ProfilePage.tsx,
views/CareerWorkspacePage.tsx) so the tree is clean for the branch integration.

Tests: +40 backend (247 total), +5 sidecar (16), +15 frontend.

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

Data/JobTrackerContext.cs

@@ -14,6 +14,7 @@ namespace JobTrackerApi.Data
     }
 
     public DbSet<Company> Companies => Set<Company>();
+    public DbSet<Job> Jobs => Set<Job>();
     public DbSet<JobApplication> JobApplications => Set<JobApplication>();
     public DbSet<Correspondence> Correspondences => Set<Correspondence>();
     public DbSet<GmailConnection> GmailConnections => Set<GmailConnection>();
@@ -42,6 +43,33 @@ namespace JobTrackerApi.Data
         modelBuilder.Entity<JobApplication>()
             .HasQueryFilter(j => CurrentUserId != null && j.OwnerUserId == CurrentUserId);
 
+        // Job (the opportunity) is tenant-owned like everything else: same deny-on-null filter,
+        // so a null CurrentUserId returns nothing rather than every tenant's rows.
+        modelBuilder.Entity<Job>()
+            .HasQueryFilter(j => CurrentUserId != null && j.OwnerUserId == CurrentUserId);
+
+        // WithMany() with no inverse navigation: Company.Jobs is already the JobApplication
+        // collection (a legacy name predating this split), so Job hangs off Company without
+        // claiming it. Restrict rather than Cascade — deleting a company should not silently
+        // destroy opportunity records that applications may still reference.
+        modelBuilder.Entity<Job>()
+            .HasOne(j => j.Company)
+            .WithMany()
+            .HasForeignKey(j => j.CompanyId)
+            .OnDelete(DeleteBehavior.Restrict);
+
+        modelBuilder.Entity<Job>()
+            .HasIndex(j => j.OwnerUserId);
+
+        // SetNull, not Cascade: an application must survive its Job row being removed, since
+        // JobApplication still carries its own copy of the opportunity columns during the
+        // Phase 0 -> Phase 1 transition.
+        modelBuilder.Entity<JobApplication>()
+            .HasOne(j => j.Job)
+            .WithMany(o => o.Applications)
+            .HasForeignKey(j => j.JobId)
+            .OnDelete(DeleteBehavior.SetNull);
+
         modelBuilder.Entity<UserRuleSettings>()
             .HasKey(x => x.OwnerUserId);