GDPopt meta-solver cannot dispatch to LDSDA (missing from _supported_algorithms) #4015

Summary

The LD-SDA algorithm (gdpopt.ldsda, merged in #3331) cannot be reached through the GDPopt meta-solver: SolverFactory('gdpopt').solve(m, algorithm='LDSDA') fails config validation because 'LDSDA' is missing from _supported_algorithms in pyomo/contrib/gdpopt/config_options.py:27. Only the direct name SolverFactory('gdpopt.ldsda') works, which is inconsistent with every other GDPopt algorithm and with the documentation pattern of selecting algorithms via the algorithm argument.

Steps to reproduce

import pyomo.environ as pyo
from pyomo.gdp import Disjunction

m = pyo.ConcreteModel()
m.x = pyo.Var(bounds=(0, 10))
m.d = Disjunction(expr=[[m.x <= 2], [m.x >= 8]])
m.o = pyo.Objective(expr=m.x)
pyo.SolverFactory('gdpopt').solve(m, algorithm='LDSDA')

Observed (main @ ce205a5, 6.10.2.dev0):

Failed casting LDSDA
to <class 'pyomo.common.config.In'>
Error: value LDSDA not in domain {'LOA': ..., 'GLOA': ..., 'LBB': ..., 'RIC': ..., 'enumerate': ...}

while pyo.SolverFactory('gdpopt.ldsda') returns a working GDP_LDSDA_Solver.

Related vestigial code in the same area

While fixing the registration it may be worth sweeping two leftovers found in the same audit:

• pyomo/contrib/gdpopt/ldsda.py:35 imports satisfiable from pyomo.contrib.satsolver and never uses it.
• _add_mip_solver_configs(CONFIG) is applied to both LD-SDA (ldsda.py:116) and LBB (branch_and_bound.py:77), but neither algorithm ever reads config.mip_solver, so the option is accepted and ignored for those two solvers.

Expected behavior

'LDSDA' (and arguably a lowercase alias, matching how 'enumerate' is listed) appears in _supported_algorithms so the meta-solver can dispatch to it; unused imports/config options removed or wired up.

Found during a GDP/MINLP roadmap audit tracked at bernalde#2; happy to submit a PR.