[FEA] LP sensitivity ranging (RHS + objective-coefficient ranges)

[cafzal]

Is your feature request related to a problem? Please describe.
cuOpt exposes shadow prices (duals) and reduced costs, but not their validity ranges — the rest of the classic LP sensitivity report:

• RHS ranging — how far each constraint's right-hand side can move before its shadow price changes.
• Objective-coefficient ranging — how far each cost coefficient can change before the current basis stops being optimal.

Duals give the marginal rate; ranging gives how far it holds — the "how much can I change this before the answer changes" companion that every LP sensitivity report provides (Excel Solver's sensitivity report; Gurobi SARHSLow/Up, SAObjLow/Up; HiGHS getRanging()). Surfaced in the same integration use as #1394.

Describe the solution you'd like
A public ranging API on the LP solution returning four arrays — objective-coefficient lower/upper per variable, and RHS lower/upper per constraint — computed from the optimal basis. The numerical primitives already exist in the dual simplex: factorize_basis, b_solve / b_transpose_solve (ftran/btran), and the ratio_test / bound_flipping_ratio_test machinery. So this is a new orchestration module (ranging ratio-tests over the existing factorization) + the public API + C API/bindings/tests — not a from-scratch solver.

Design questions:

1. PDLP semantics — ranging needs a basis, so it applies to the dual-simplex (or post-crossover) path; PDLP-only returns unavailable. Define behavior.
2. API shape — a single getRanging()-style struct vs. four accessors.
3. Degeneracy — ranges are ill-defined / one-sided at degenerate vertices; the report should flag rather than mislead.

Describe alternatives you've considered

• Approximating ranges by re-solving with perturbed RHS / cost (finite differences) — many extra solves, inexact, and it doesn't recover the exact breakpoints the basis gives for free.

Additional context

• Builds on the basis-status request [FEA] Expose basis / variable status on the LP solution (companion to reduced costs) #1394; together they complete cuOpt's LP sensitivity report.
• Companion to skills doc PR Note dual/sensitivity support per problem type in formulation skill #1393.
• Bigger than [FEA] Expose basis / variable status on the LP solution (companion to reduced costs) #1394 (a numerical module vs. a getter), dual-simplex-only, but the primitives are already present.
• Prior art: HiGHS getRanging(), Gurobi sensitivity attributes (SARHSLow/Up, SAObjLow/Up).
• Discovered via cuOpt × Frontier integration testing; will be showcased by planned examples with AI-guided sensitivity analysis

Related: the diet LP duals example — NVIDIA/cuopt-examples#154 — already adds shadow prices + reduced costs; ranging slots in here as their validity ranges.