fix: improve scheduler startup resilience on low-resource Postgres

[Theauxm]

Summary

• Orphan manifest pruning timed out on a 2 vCPU Postgres instance because EF Core inlined 5000+ expected external IDs as NOT IN(...) string parameters, overwhelming the query planner. The fix loads all manifest ID pairs with a lightweight SELECT and computes the orphan set in C#, then deletes in batches of 500 by integer PK.
• RecoverStuckJobs now uses batched ExecuteUpdateAsync instead of loading all stuck metadata into memory — matches the reap junction pattern.
• New MaxWorkQueueEntriesPerCycle config (default: 200, null = unlimited) caps how many work queue entries CreateWorkQueueEntriesJunction creates per manifest manager cycle, preventing write bursts after extended downtime.
• Applied the same server-side filtering pattern to PruneStaleManifestsAsync in TraxScheduler for consistency.

Test plan

• All 650 integration tests pass
• All 113 unit tests pass
• New integration tests for large expected ID sets (100 expected + 5 orphans, 50 expected + orphan with FK data)
• New integration test for orphan count exceeding batch size (510 orphans)
• New integration test for stuck job count exceeding batch size (510 stuck jobs)
• New integration tests for MaxWorkQueueEntriesPerCycle (limit=3 with 10 due, null with 10 due)
• Stress test: 5000 orphans pruned in 226ms across 10 batches (500 expected kept)
• Stress test: large expected set scenario (450 expected, 50 pruned)
• Zero build warnings, CSharpier formatted

[traxsharp]

This PR is included in version 1.24.1