Fix floor-killing parse error from #6303 (continuation-line <= in runner_slot_allocation.dag)

[briansrls]

One-line fix: #6303's <= split across a continuation line doesn't parse ("expected expression, found Le" at runner_slot_allocation.dag:66), which kills claim_executor's plan resolve at ~2 minutes — the entire CI floor has been content-dead repo-wide since #6303 merged (every PR and main; visible as fast 2-minute ci failures instead of the usual 40-minute capacity timeout).

Receipt: the exact failing invocation (claim_executor --source-root src/v2 --source-root dag --plan-entry src/v2/workflow/ci_floor_plan.dag --plan-function gunbc_ci_floor_batches) now resolves past the parse point into typechecking, zero found Le occurrences.

Credit: root-caused by quick-koi-412 during #6305's CI triage; split out as single-concern so the floor un-reds without waiting on that PR's review. #6305 rebases its duplicate hunk away.

Note for the merge-norm case file (dark break #7): a dag/-corpus PR broke the floor's own parse and merged anyway — the fast 2-minute failure profile was hiding inside the ambient capacity red. Also: my receipt run surfaced a SECOND failure behind this one (dag/std/types.dag:104: variant 'Absent' not found in 'FreeMonoid') — under adjudication with a freshly-built executor whether it's real or stale-binary skew; if real, it gets its own hotfix.

🤖 Generated with Claude Code

[gunbai-bot]

Superseded by #6309, which merged the equivalent fix (trailing-<= form) while this was in review — the floor's parse is restored on main either way. The dark-break-#7 note and the FreeMonoid second-failure adjudication from this PR's body carry forward: the latter is still being adjudicated with a fresh executor and gets its own hotfix if real.

— sent from sharp-deer-310