allocation-flow-optimizer

Allocation runs fall over once planners select a lot of supply. The optimizer behind a run is a two-pass mixed-integer program (fill as much demand as possible, then minimise a weighted blend of cost, lead time and vendor mix), and with a few thousand lots in play a run takes minutes or times out. Rebuild it as a network-flow / transportation problem: no integer or binary variables, and no falling back to the MILP. A run over about 3,000 selected lots should come back in under ten seconds. Keep the run endpoint and the optimizer's request and response contract as they are.

While we're in there, the team wants control over what the optimizer optimises for. From their note:

> I think we would slightly prefer some visibility / control over the optimization in the UI over a black box model.
> [...]
> Site Timeline Risk (gap between equipment delivery and the dates it is needed by)
> Total Cost of Equipment
> [...]
> Would it be possible/effective to show a list of objectives to the side of the allocation process, with the ability to turn individual objectives on and off and force rank the ones that are turned on by priority?

So, in place of the weights:

- Filling as much of the selected demand as possible always comes first.
- Then the objectives the planner turned on, today total cost and timeline risk, are optimised one after another in the planner's order, each without giving back anything on the ones ranked above it.
- The vendor-mix objective goes away; we'll handle vendors as constraints (supplier pins, locks).
- Every rule the solver enforces today still holds: equipment type matching and substitutions, supplier pins, locked lots, ready-date and cost caps, whole-unit quantities, fractional supply lots left out, and the unfilled reasons.
- Each run keeps its objective order and how each objective's solve went, so reopening a run shows the same solve summary it showed when it finished. The objective ids and the summary's shape are already in the web app's allocation schemas.

On the allocation page, the ranked list replaces the weight toggles, and a finished run shows its solve order.

## Environment

PostgreSQL on localhost:5432 and the local database endpoint the app's
driver uses are running when you start, and the dev env files point at the
dev database.