refactor(solver): validation, sanitize kwargs, and result wiring on Solver path

[FBumann]

Stacked on #690. Closes the gap between Model.solve() and Solver.from_name(...).solve().

Core principle

Solver.from_model() does not mutate the model. Model-state transformations are Model-level primitives, called explicitly:

model.constraints.sanitize_zeros()        # drop zero-coefficient terms
model.constraints.sanitize_infinities()   # drop trivial <= +inf / >= -inf rows
model.apply_sos_reformulation()           # rewrite SOS as binary + linear (#690)
model.undo_sos_reformulation()            # restore the original SOS form (#690)

Model.solve() calls these internally as orchestration. The low-level Solver path expects the caller to apply them — no silent mutation on build.

Canonical low-level pattern:

model.constraints.sanitize_zeros()   # optional preprocessing
solver = Solver.from_name("highs", model, io_api="direct")
result = solver.solve()
model.assign_result(result, solver=solver)

What lives where after this PR

Port? = should it move to Solver. Status = ✅ done · ⬜ todo · — n/a.

Item	Port?	Status	Where (on Solver or why not)
Quadratic / semi-continuous feature gates	yes	✅	Solver._validate_model() (build-time, called from _build())
SOS feature gate	yes	✅ (#690)	Solver._validate_model() (build-time)
Empty-objective check	yes	✅	Solver.solve() (run-time); scoped dup in Model.solve()'s remote branch, removed by #683
Result wiring (model.solver + primal/dual/status)	yes	✅	Model.assign_result(result, solver=...) (post-solve)
Build-time kwargs: io_api, explicit_coordinate_names, set_names, problem_fn, slice_size, progress, **solver_options	yes	✅	Solver.from_model(...)
Run-time kwargs: basis_fn, warmstart_fn	yes	✅	Solver.solve(...)
env, log_fn	yes	⬜	accepted on both from_model() and solve() today; PR3 consolidates to from_model() only (13 subclasses)
sanitize_zeros / sanitize_infinities	no	—	Model-level: model.constraints.sanitize_*(). Mutates — caller-owned.
SOS apply/undo lifecycle	no	—	Model-level: model.apply_sos_reformulation() / undo_sos_reformulation() (#690). Mutates — caller-owned.
reformulate_sos (True/False/"auto")	no	—	Model.solve()-side convenience wrapping model.apply_sos_reformulation(). Solver-path users call apply/undo directly.
OETC remote (remote=OetcHandler(...))	yes	⬜ (#683)	refactor into a Solver subclass
Generic remote=RemoteHandler(...)	?	—	could follow #683
mock_solve=True	?	—	could become a Mock Solver subclass
"Any solver installed" raise	?	—	Solver.__post_init__ covers "this-installed"; "any-installed" is module-level
solver_name auto-pick, default solution_fn, keep_files cleanup, info logs, reset_solution()	no	—	orchestration: belongs above the Solver layer

Docs follow-up. Keeping sanitize off the Solver kwargs makes it less discoverable for users coming from Model.solve(). The user guide / example notebooks should surface the model-level primitives — separate doc PR #685, not in scope here.

[FabianHofmann]

this is extremely sensible! I did not think about model mutations in the solver refactor pr. thanks for addressing this. let me know when this is ready to review

[FabianHofmann]

very good catch!

[FabianHofmann]

we definitely need a helper function that makes these skips snappy

[FBumann]

this is extremely sensible! I did not think about model mutations in the solver refactor pr. thanks for addressing this. let me know when this is ready to review

It is ready, but i think its less about correctness, but more about the conceptual split between Model and Solver, and the ergonomics for users using the new Solver class