Separate CHASM scheduler buffer planning

[chaptersix]

What changed?

• Add a pure buffer planner in the scheduler-private internal package. It consumes immutable value snapshots, uses an explicit evaluation time, and returns request-ID-keyed decisions without pointers into live CHASM state.
• Separate buffer processing into planning, transactional application, and applied-outcome metric recording.
• Re-resolve each planned request against current persisted state before mutation, consume scheduled-action capacity only after successful revalidation, and route lifecycle changes through the PR 2 transition helpers.
• Make the planner the unconditional production path and remove scheduler.enableBufferPlanner.
• Move the legacy processor into test-only code and retain it as the differential oracle.
• Preserve legacy ready-start ordering: ALLOW_ALL starts consume limited capacity before the selected non-overlapping start.

Production behavior is intended to remain unchanged. Only one path applies mutations or emits tasks, and metrics are recorded from the applied outcome rather than speculative decisions.

Why?

This is PR 3 of the CHASM scheduler readability stack. It makes overlap, catch-up, action-capacity, and lifecycle decisions independently readable and testable. The bounded state-space comparison provides enough parity evidence to remove the runtime fallback while keeping the legacy implementation as executable proof.

Stack

• PR 0: Characterize CHASM scheduler task validity #35, main <- sch-readable
• PR 1: Separate CHASM scheduler action capacity APIs #36, sch-readable <- sch-readable-action-capacity
• PR 2: Centralize CHASM scheduler lifecycle transitions #38, sch-readable-action-capacity <- sch-readable-lifecycle
• PR 3 (this PR): Separate CHASM scheduler buffer planning #39, sch-readable-lifecycle <- sch-readable-buffer-planner

Differential coverage

The comparison seam deep-clones equivalent inputs and compares persisted Scheduler and Invoker state, emitted task identity and ordering, cancel/terminate requests, metrics and tags, named outcomes, RemainingActions, and conflict-token deltas.

The deterministic state-space tests perform 29,140 legacy-versus-planner comparisons across:

• every ordered overlap-policy sequence through length four, with and without a running workflow and across unlimited/exhausted/limited capacity;
• duplicate and alternating request IDs;
• every default overlap policy with UNSPECIFIED in every position;
• catch-up windows below, equal to, and above the minimum, including exact deadline and desired-time boundaries;
• manual/automatic, paused/running, and action-capacity combinations;
• deferred, unprocessed, ready, retrying, running, completed, and completion-before-start lifecycle states.

This is exhaustive over those bounded semantic classes, not over the unbounded input space. It found the limited-capacity ready-ordering divergence fixed in this PR.

How did you test it?

• built
• run locally and tested manually
• covered by existing tests
• added new unit test(s)
• added new functional test(s)

make fmt-imports
go test -tags test_dep ./chasm/lib/scheduler/internal ./chasm/lib/scheduler -count=1
make lint-code
git diff --check

The functional suite was intentionally left to the PR checks.

Potential risks

There is no runtime fallback after this change. During a mixed-version rollout, older nodes continue to use the legacy implementation and newer nodes use the planner. The differential tests pin state, task, metric, action-count, conflict-token, duplicate-ID, and boundary behavior between those implementations.