fix(objectives): ignore work prefer-early-tours cannot move

[hutchinsp01]

What

prefer-early-tours scored every shift in use. A shift held open by work the solver cannot move therefore counted as already paid for, and new work was drawn onto it in preference to an earlier empty day — the opposite of what the objective is for.

With Monday the fleet's earliest shift and a standing appointment pinned to Thursday by a relation:

where a new job goes	shifts counted	fitness
Thu, joining the appointment	{Thu}	3 days
Tue, opening a shift	{Tue, Thu}	1 + 3 = 4 days

Joining the late shift always wins, and it is not only the insertion estimate — fitness already charged Thursday unconditionally, so adding Tuesday could only make the sum worse.

This scores shifts carrying work the solver could have placed elsewhere instead. Only the first such job on a shift is charged, so the per-tour behaviour from #17 is unchanged, and a plan with no pinned work behaves exactly as before.

What is not new work

The feature takes the existing jobs — those already committed to a shift before the solve:

create_prefer_early_tours_feature(name, origin, existing_jobs: HashSet<Job>)

The pragmatic reader fills that from the problem's locks, which covers every relation type. It reads the locks rather than SolutionContext::locked, which is not the same set: only strict and sequence relations reach the solver as locked jobs, an any relation lands in reserved instead, and locked is additionally extended at runtime with reload and recharge jobs. Reading it would both miss real pins and invent ones that are not there. There is a test on strict specifically because it exercises the path any does not.

Separately, core skips any job that names a vehicle. VehicleId is a core job dimension set only on the break, reload and recharge jobs generated for a single vehicle shift, so this is a rule core can state for itself rather than something the format has to describe. None of those jobs can be taken on another day.

Breaks are why that second rule earns its place: one is required as soon as its route exists and the tour's span covers the break window, so counting it priced the break at its shift's delay — and since this objective outranks cost, the solver preferred to drop the break rather than pay it.

	resulting late tour
break counted as movable	departure, standing, arrival — break silently dropped
break excluded	departure, [standing, break], arrival

So a fleet using breaks alongside this objective was losing them.

Ordering caveat

Unchanged from #17, but pinned work makes it much easier to hit: ranked below minimize-tours, new work still consolidates onto a shift a pinned job has already opened, because that saves a tour. The behavioural tests here leave minimize-tours out for exactly that reason. Noted on the enum variant.

Trade-off

New work will now open an earlier empty shift rather than joining a later one that is already staffed, which can cost an extra vehicle day. That is the intent — rank minimize-tours above if consolidating is worth more than earliness.

Testing

Full workspace suite passes. Coverage is deliberately thin — two vrp-core unit tests and one end-to-end pragmatic test — but each was checked against the unfixed code rather than just asserted to pass:

perturbation	outcome
neither exclusion (previous behaviour)	both crates fail
existing jobs excluded, vehicle-bound ones still counted	both crates fail on the break
as proposed	all pass

The core fitness test's last two cases are the regression pair: joining the appointment's shift scores four days against one for opening an earlier shift, where previously it scored four against five and joining won.

No version bump is included in this branch.

🤖 Generated with Claude Code