FIBERALLOC-62: Add a HiGHS solver backend

[monodera]

https://pfs-jira.naoj.org/jira/browse/FIBERALLOC-62

Adds HiGHS (through highspy) as a third solver backend
for the netflow MILP, alongside Gurobi and PuLP — an open-source option that
does not require a Gurobi licence.

Changes

• HighsProblem backend (ets_fiber_assigner/netflow.py), following the
  same LPProblem interface as GurobiProblem and PulpProblem. Columns are
  reserved on addVar() and created in a single _flush() batch, because
  adding them one at a time through highspy costs ~50 us each.
• solve() raises when no solution was produced. Unlike Gurobi, HiGHS
  hands back an all-zero column vector for an infeasible or unsolved model,
  which is indistinguishable from a feasible solution that assigns nothing;
  the model status is now checked so callers cannot silently read a failure
  as an empty assignment.
• New buildProblem() parameters solver and solverOptions.
  solver="gurobi" | "pulp" | "highs" selects the backend, and
  solverOptions passes options in that backend's own parameter names.
  When solver is None the existing gurobi flag behaves exactly as
  before, so current callers are unaffected.
• README: the solver paragraph in the prerequisites now lists HiGHS.

highspy is imported lazily inside HighsProblem.__init__, the same way
gurobipy and pulp are, so it is only needed when that backend is used and
no new hard dependency is introduced.

Update (commit 8043410): batched rows, Gurobi-consistent read rules, tests

• Rows are batched like columns. add_constraint() used to hand every row
  to Highs.addConstr, ~19 us per row (highspy's unique_elements 9.5,
  addRow 4.8, passRowName 0.9, wrapper 3), i.e. 10-17 s per million rows.
  Rows are now collected in flat typed arrays (_RowBuffer) and passed to
  HiGHS in one addRows call at the next flush, ordered within each row the
  way unique_elements orders them, so the stored matrix and the written
  .lp/.mps are byte-identical to the one-row-at-a-time path. ~2 us per
  row: a 625k-row synthetic model builds its rows in 1.2 s instead of 12.5 s,
  a 147k-row real instance (20000 targets, 4 pointings, cobraOps Bench) in
  18.8 s instead of 21.6 s, with identical objective and assignment.
• Names go to HiGHS only in dump(). HiGHS's own log refers to rows and
  columns by index whether or not they are named, so nothing is lost; to see
  names, read the file dump() writes.
• Read rules follow GurobiProblem. value() raises when there is no
  valid solution: before solve(), after a failed solve(), or once a change
  (new columns or rows, changeVarBounds) has been applied by update(),
  dump() or solve(); a still-pending change leaves the previous solution
  readable, as a pending Gurobi modification leaves var.X.
  changeVarBounds() itself is pending until the next flush, like a Gurobi
  bound change until update(). dump() before solve() writes an empty
  objective, as GurobiProblem.dump() does.
• Docstring lists the HiGHS options relevant here with their defaults
  (mip_rel_gap 1e-4 equals Gurobi's MIPGap default), notes that
  varBounds/changeVarBounds are instance methods on this backend (calling
  them through the class does not work), and that highspy >= 1.15 is required
  (module-level highs_var).
• Tests and tools. tests/test_highs_problem.py (pytest, 27 tests, < 1 s):
  backend behaviour, identity with highspy's own addVariable/addConstr
  path, known optima, and agreement with GurobiProblem on the same models
  (skipped without gurobipy; the pip wheel's size-limited licence suffices).
  misc/bench_highs_problem.py is the synthetic benchmark used for the
  numbers above; misc/compare_highs_real_instance.py builds one real
  instance with solver="gurobi" and solver="highs" through buildProblem
  and compares model content, objective and assignment (identical on a
  300-target instance).

Benchmark

Benchmarked on 22 real target lists: HiGHS finished the same 20 that Gurobi
did, at 1.08x the total runtime, with pointing counts agreeing to within the
spread a single solver shows across repeated runs of the same input.

Notes

• The ChangeLog is intentionally left untouched here; entries are added
  separately on release.
• Known and deliberately not addressed: the demo scripts read binary variable
  values with > 0, which is not tolerance-safe for the near-integral doubles
  a MIP solver returns. The demo scripts are considered obsolete, so no fix is
  planned for now.

🤖 Generated with Claude Code