Cut-pool management for cross-scenario and xhat feasibility cuts

[DLWoodruff]

Background

The CrossScenarioExtension (mpisppy/extensions/cross_scen_extension.py) installs per-iteration cuts into every local scenario's s._mpisppy_model.benders_cuts ConstraintList, keyed by (outer_iter, scen_name). Those entries are never removed — only the inner_bound_constr gets pruned (to keep just the tightest bound). benders_cuts accumulates unboundedly over the life of a run.

The proposed xhat feasibility-cut feature (see doc/xhat_feasibility_cuts_design.md, addresses issue #601) will install cuts the same way, so it inherits the same unbounded growth.

Impact

For long runs — especially on problems where each PH iteration triggers a fresh cross-scen cut round, or where an xhatter finds many distinct infeasible candidates — the per-scenario subproblem accumulates constraints indefinitely. Persistent-solver warm starts still work, but solver times grow as the model bloats, and eventually dominate.

What this issue asks for

A shared cut-pool-management strategy that both extensions can use. Options to consider:

1. Hard cap per scenario. Keep at most N cuts; drop the oldest on overflow.
2. LRU / "not binding for K iterations" prune. Track whether each cut was at its bound in the last K solves; drop cold ones.
3. Age-based prune. Drop cuts older than M outer iterations.

The strategy should live in a small utility (candidate name: mpisppy.utils.cut_pool) so both extensions call the same code. Persistent-solver-aware removal (solver.remove_constraint(...)) has to be part of it.

Relation to other work

• doc/xhat_feasibility_cuts_design.md (upcoming PR for issue Xhatters should optionally generate feasibility cuts #601) calls out this gap in its "Cut pool management" open question and defers to this issue.
• The cut_installer helper proposed in the same design doc is a natural home for the pruning symmetry.

[bknueven]

My suggestion would be that we don't use per-scenario cuts at all, and instead use aggregate L-shaped cuts. This also avoids the issue of the number of cuts "blowing up" with the number of scenarios.