fix(seed): simulation profile cannot validate above HistoryDays≈107 — lock sweep runs once, batched at 200 #638

Discovered while loading the simulation fixture into a local debug database at Simulation__HistoryDays=730.

What happens

seed --profile simulation exits 1 with a count mismatch that is only ever about the daily-entry lifecycle split:

Simulation seed completion check failed — the seed is short/partial and must NOT be marked complete:
… dailyEntries.submitted: expected 10, got 1070; dailyEntries.locked: expected 1446, got 633 …

Why

• SimulationDataSeeder.SeedAsync calls lockSweep.RunAsync(ct) once (SimulationDataSeeder.cs:397).
• DailyEntryLockSweep.LockDueEntriesAsync takes .Take(BatchSize) with BatchSize = 200 (DailyEntryLockSweep.cs:21) — one call locks at most 200 entries and returns; the sweep is designed to be re-polled by DurableJobWorker, which never starts in a run-then-exit verb.
• ExpectedLockedEntryCount mirrors the sweep’s cutoff rule and therefore expects every eligible entry locked: FlockTopologyCount × (HistoryDays − LockAfterDays).

Those agree only while 2 × (HistoryDays − 7) ≤ 200, i.e. HistoryDays ≤ 107. Above that the assertion can never be satisfied, on any database, however clean.

The class header at SimulationDataSeeder.cs:1890 claims the expectations are "depth-robust by construction". They are, arithmetically — but the seeding is not, so the claim reads as broader than it is.

Blast radius today

Low, and that is why it went unnoticed: the harness default is HistoryDays=90 and the test fixture is 12, both under the ceiling. It only bites someone deliberately asking for a deep fixture.

Note the failure is also post-commit: the check runs in EmitManifestAsync after every row is written, in no transaction, so an over-ceiling run still leaves its data behind — just unlocked past the first 200, with no manifest and a red exit.

Suggested fix

Drain the sweep in the seeder rather than assuming one pass is enough — re-invoke until a pass locks nothing, with a bound so a genuine bug cannot spin forever. Do not raise BatchSize: that is a serving-path constant sized for the background worker, and changing it to satisfy a seeder would move the ceiling rather than remove it.

Then add a test at a depth above the current ceiling (e.g. HistoryDays=120) that asserts a green seed — one that fails today.

Docs

docs/runbooks/simulation-fixture-on-a-dev-database.md documents the ceiling and points here. Remove that section when this closes.