feat(scheduler-allocation): implement parjob's combinatorial plan generation

Add the real xce_alloc_plan_iter_t for parjob: for host-count k=1..maxTasks
(ascending, most-preferred-first), generate one balanced partition of
maxTasks into k buckets (floor/ceil split, remainder to the first rem
buckets), which is descending by construction. Pure function of maxTasks
alone -- never dereferences sched -- with a real pthread_testcancel()
cancellation point and stable post-exhaustion NULL (Req 2.1-2.6, 4.1).

my_alloc()/parjob_prepare_allocation() remain untouched stubs; wiring the
iterator into real allocation is task 4.2.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XYdtrEWWZfKRRGED7raEYg

.kiro/specs/scheduler-allocation/tasks.md

@@ -51,7 +51,7 @@
   - _Depends: 3.1_
 
 - [ ] 4. Core: parjob combinatorial allocation
-- [ ] 4.1 Implement parjob's lazy combinatorial plan generation
+- [x] 4.1 Implement parjob's lazy combinatorial plan generation
   - Generate candidate plans as a pure function of a job's task count: ascending host-count order, one balanced partition per host-count, descending bucket order within each plan
   - Ensure each call advances a real cancellation point and that plan generation never inspects live worker state (a pure function of the task count alone)
   - Write a unit test proving one-plan-per-call generation, most-preferred-first ordering (including an uneven split, e.g. splitting 7 tasks across 3 hosts), and a stable exhaustion signal