Resolve CoreSolver mutable+return state pattern

[jc-macdonald]

The CoreSolver class conflates mutating internal state with returning values from the same methods. This makes unit testing individual methods difficult and creates unclear contracts.

Problem

As Tim noted: 'there is the confluence of mutating state and returning state that I think makes it a nightmare to unit test the class currently' — e.g., methods that both mutate self and return a property of self (L772).

Proposed direction

• Methods should either mutate self and return None, or compute and return a value without side effects
• Consider a builder/result pattern: CoreSolver builds the plan, a separate SolverResult holds output
• This may naturally align with the Backend Abstraction milestone (Define LinearSolverBackend protocol and tighten operator contracts #19, Inject backend into CoreSolver #21, Protocol-first backend abstraction for swappable solver backends #26) which already plans to inject backends and define protocols

Related

• Backend Abstraction milestone (overlapping concerns)
• Refactor step-function dispatch (_build_step_func) #30 (dispatch refactor)
• Move validation logic from CoreSolver to RunConfig/RunPlan #31 (validation placement)

Ref: PR #18 review by @TimothyWillard (L1, L772)