gdpopt.enumerate raises bare TypeError for unbounded or float-bounded integer variables

[bernalde]

Summary

gdpopt.enumerate with force_subproblem_nlp=True builds the integer realizations with

# pyomo/contrib/gdpopt/enumerate.py:76 (_discrete_solution_iterator)
discrete_var_values = [range(v.lb, v.ub + 1) for v in discrete_var_list]

so any unbounded integer variable produces a bare TypeError instead of a meaningful error, and integer variables with float bounds (e.g. bounds=(0.0, 2.0)) crash the same way even though the enumeration is well defined.

Steps to reproduce (no external solvers needed — the crash happens before any subsolve)

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

m = pyo.ConcreteModel()
m.x = pyo.Var(bounds=(0, 10))
m.n = pyo.Var(domain=pyo.Integers)          # unbounded integer
m.d = Disjunction(expr=[[m.x <= 2], [m.x >= 8]])
m.o = pyo.Objective(expr=m.x + m.n)
pyo.SolverFactory('gdpopt.enumerate').solve(m, force_subproblem_nlp=True)

Observed (main @ ce205a5, 6.10.2.dev0):

TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'

and with m.n = pyo.Var(domain=pyo.Integers, bounds=(0.0, 2.0)):

TypeError: 'float' object cannot be interpreted as an integer

Expected behavior

• Unbounded (or partially bounded) integer variables: a GDP_Error naming the offending variable and stating that enumeration over integer realizations requires finite bounds (mirroring how other GDPopt algorithms report unusable models).
• Float-valued but integral bounds: coerce with floor/ceil (range(math.ceil(v.lb), math.floor(v.ub) + 1)) rather than crash.

Found during a GDP/MINLP roadmap audit tracked at bernalde#2; happy to submit a PR with tests for both cases.