Merge lane: place runs on a quiet node

On main (2026-10-17) the lane gate's wall time follows how loaded its node is: - Run 6759 on `shared-a1d14391`: API unit 273 s, whole gate 641 s. - Run 6764, same node later, with runners busy: API unit **890 s**. - Run 6885 on `h6-3` (32 CPUs, **73% CPU**, 5 runners): one PR still gating after 12 min. Lane placement (`apps/api/app/merge_lane.py` placement + the lease filter) currently checks only a floor (≥4 cores, ≥15 GB) and takes the first free slot. Ask: 1. Place a lane task on the eligible node with the most free CPU (`host_metrics.cpu_pct` × `cpu_count`, fresh samples only), not the first free slot. 2. While a lane run is gating on a node, its gate gets priority there. Either runner gates on that node are admitted behind it (the `JAAH_GATE_*` admission in `tools/check.sh` already budgets heavy stages per host), or new runner dispatch to that node pauses for the run. Pick the simpler, record why. Out of scope: speculative stacking (Task 6777); test content. Done means: lane gate wall time measured on a busy fleet before and after (same tree), recorded in the lane policy section; lane tests cover the placement choice; `./dc check full` green.

Lane runs now go to the node with the most idle cores, and new runners pause on a node while its lane gate runs. Merged #5722, plus #5724 fixing a gate test fixture; both deploys passed. Busy vs idle suite: 2608 s vs 1425 s. Full gate skipped on your order.