scan-next: abandon candidate search on high-V start extents
The Plan A coverage search is O(V^2) in the boundary count and holds the
start extent's Exclusion for its whole duration, so a start extent that
accumulates a large, dense match pool can pin a worker and starve every
task queued behind that extent. scan_next_plan_shortest_path already
falls back to the linear greedy cover above rewrite.plan-max-vertices,
but candidates kept flowing into the plan: the Planner loop dispatched
every candidate to every plan and only stopped globally once no plan
continued, so as long as Plan B still wanted candidates Plan A's pool —
and its V — kept growing.
Raise the abandon decision to the two places that act on it.
update_continues() now clears continues() once the accumulated boundary
count exceeds the vertex budget, and the Planner loop skips any plan
whose continues() is already false instead of feeding it more
candidates. Together these stop Plan A's pool from growing past the
point where the greedy fallback has taken over, while its best-so-far
still enters selection via finalize(), competing against Plan B and the
do-nothing floor.
The loop skip also stops feeding a fully-covered Plan A (its existing
coverage-based continues()=false) and the always-false do-nothing plan
(whose process_candidate is a no-op), neither of which could benefit from
further candidates.
projects / bees / commit