docs(specs): reconcile stale metadata found auditing stalled specs

- scheduler-sim-eager-reconciliation: all 9 tasks were done (last:
  task 3.3 full regression, commit 446437bf, 2026-08-27) but the 3
  section-header checkboxes were never flipped and phase stayed at
  tasks-generated. Same drift class as 5c82ad0b/b14e53f5. Checked the
  3 headers, bumped phase to implementation-complete.
- scheduler-allocation, scheduler-preemption: blocked_on named
  scheduler-core and scheduler-dispatch-commit, both of which reached
  implementation-complete weeks ago (2026-08-19, 2026-08-24). Annotated
  as resolved rather than removed, so the historical block reason
  stays visible. Requirements approval is still outstanding on both --
  not touched, since that gate needs human review.

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

.kiro/specs/scheduler-allocation/spec.json

@@ -21,7 +21,9 @@
     }
   },
   "ready_for_implementation": false,
-  "blocked_on": ["scheduler-core", "scheduler-dispatch-commit"],
+  "blocked_on": [
+    "RESOLVED 2026-09-03: scheduler-core reached implementation-complete (2026-08-19). scheduler-dispatch-commit reached implementation-complete (2026-08-24), including bug-1624 (task 2.1/3.1, 2026-08-23), the resInUse/sharedInUse corruption this spec's try_alloc_on_host() sequencing note was waiting on. Neither dependency remains blocking; requirements.md still awaits approval before design can proceed."
+  ],
   "sibling_specs": ["scheduler-core", "scheduler-preemption", "scheduler-dispatch-commit"],
   "sequencing_note": "Added 2026-08-23 (user directive): blocked on scheduler-dispatch-commit landing first -- this spec's try_alloc_on_host() reads the same resInUse/sharedInUse totals bug-1624 (fixed by scheduler-dispatch-commit) corrupts, and the planned XCE_ALLOC_PREEMPT borrowing mode interacts with what counts as committed/borrowable under that spec's redefined RUN-state timing."
 }

.kiro/specs/scheduler-preemption/spec.json

@@ -21,6 +21,8 @@
     }
   },
   "ready_for_implementation": false,
-  "blocked_on": ["scheduler-core"],
+  "blocked_on": [
+    "RESOLVED 2026-09-03: scheduler-core reached implementation-complete (2026-08-19). No remaining dependency blocker; requirements.md still awaits approval before design can proceed."
+  ],
   "sibling_specs": ["scheduler-core", "scheduler-allocation"]
 }

.kiro/specs/scheduler-sim-eager-reconciliation/spec.json

@@ -1,9 +1,9 @@
 {
   "feature_name": "scheduler-sim-eager-reconciliation",
   "created_at": "2026-08-22T14:50:13Z",
-  "updated_at": "2026-08-22T14:58:00Z",
+  "updated_at": "2026-08-27T06:13:12Z",
   "language": "en",
-  "phase": "tasks-generated",
+  "phase": "implementation-complete",
   "approvals": {
     "requirements": {
       "generated": true,

.kiro/specs/scheduler-sim-eager-reconciliation/tasks.md

@@ -1,6 +1,6 @@
 # Implementation Plan
 
-- [ ] 1. Core: widen reconciliation's capture eligibility to any not-yet-captured job
+- [x] 1. Core: widen reconciliation's capture eligibility to any not-yet-captured job
 - [x] 1.1 Prove and implement state-independent capture of a job's recorded dispatch allocation
   - Replace the existing test that locks in the bug (asserting a not-yet-running job must never be reconciled) with one asserting the opposite: a job whose recorded dispatch decision is found this round gets its allocation captured regardless of whether it has reached a running state yet
   - Run the new/updated test against the current code first to confirm it fails for the expected reason (the old state-gated behavior), then remove the state precondition from the capture-eligibility check so only "not yet captured" remains
@@ -17,7 +17,7 @@
   - _Requirements: 3.1, 3.2, 4.1, 4.4_
   - _Boundary: sim_reconcile_unaccounted_jobs_
 
-- [ ] 2. Integration: prove captured-but-not-running allocations stay excluded from resource-in-use accounting until the job actually runs
+- [x] 2. Integration: prove captured-but-not-running allocations stay excluded from resource-in-use accounting until the job actually runs
 - [x] 2.1 Verify resource-in-use accounting defers to the job's real running state, not its capture time
   - Drive a captured, not-yet-running job's allocation through the resource-in-use recomputation and confirm it contributes nothing to worker or shared resource usage
   - Transition that same job to a running state and drive resource-in-use recomputation again, confirming its allocation now contributes from that point forward
@@ -26,7 +26,7 @@
   - _Boundary: sim_reconcile_unaccounted_jobs, sched_account_jobs_
   - _Depends: 1.1_
 
-- [ ] 3. Validation: end-to-end proof under contention, decision-verification mode, and full regression
+- [x] 3. Validation: end-to-end proof under contention, decision-verification mode, and full regression
 - [x] 3.1 (P) Verify correct capacity accounting under resource contention with realistic dispatch-to-confirmation separation
   - Build a replay fixture where a worker's capacity is insufficient for every candidate job, with dispatch decisions and their running-state confirmations recorded several rounds apart
   - Confirm the live capacity check sees the correct, non-zero resource-in-use total at each round rather than treating capacity as permanently free