[Refactor] Replace good_lp with thin ILP backend trait for direct solver control

[isPANN]

Motivation

During investigation of #780, we discovered that good_lp introduces several risks:

1. Version drift — CI resolved good_lp 1.15.0 while the lockfile had 1.14.2, with no warning. The newer version may have changed solver option behavior, contributing to incorrect MIP results on CI.
2. Opaque option passing — Setting presolve: "off" goes through good_lp → highs → highs-sys (three layers), making it hard to verify options actually reach HiGHS.
3. Abstraction leakage — Debugging solver issues requires penetrating good_lp internals, which defeats the purpose of the abstraction.
4. Unnecessary generality — The project only uses HiGHS, but good_lp pulls in multi-solver infrastructure.

Proposal

Replace good_lp with a thin ILPBackend trait:

trait ILPBackend {
    fn solve(
        &self,
        num_vars: usize,
        constraints: &[LinearConstraint],
        objective: &[(usize, f64)],
        sense: ObjectiveSense,
        options: &SolverOptions,
    ) -> Option<Vec<f64>>;
}

Each backend (HiGHS, Gurobi, CPLEX) directly calls its native crate (highs, grb, cplex-rs), feature-gated:

• ilp-highs → highs crate (current default)
• ilp-gurobi → grb crate (future)
• ilp-cplex → cplex-rs crate (future)

Benefits

• Direct control over solver options (presolve, tolerances, heuristics)
• Only one layer of abstraction to debug
• Each backend can expose solver-specific tuning
• Cleaner feature gating without good_lp's transitive dependencies

Scope

• Remove good_lp dependency
• Implement HiGHSBackend using highs crate directly
• Migrate src/solvers/ilp/solver.rs to use the new trait
• Leave Gurobi/CPLEX backends as future work

Context

See #780 root cause analysis for details on how good_lp version drift contributed to CI failures.