Document active-power limit constraints for thermals and loads

Start by reading the referenced sections of electric_loads.jl and thermal_generation.jl, especially the constraint-building methods and their named helpers. Record the existing constraint keys, meta strings, bounds, and row-counting conventions in project documentation, including the listed inconsistencies. Done means the current behavior is documented without proposing fixes.

Context

The active-power upper/lower-bound constraint machinery across thermal and load device families uses a mix of constraint types, meta strings, and row-counting conventions that isn't documented anywhere. This issue captures the current state on paper, as a prerequisite to deciding what's intentional design vs. accumulated technical debt.

All keys below are ConstraintKey(ConstraintType, ComponentType, meta).

Loads

InterruptiblePowerLoad with PowerLoadInterruption + forecast attached:

Plus a JuMP variable lower bound p ≥ 0 from get_variable_lower_bound (electric_loads.jl:9). There is no ActivePowerVariableLimitsConstraint row for the nameplate — the nameplate UB is enforced via the JuMP variable's upper bound, not a constraint.

PowerLoadDispatch omits the "binary" row (no OnVariable) and otherwise looks the same.

Thermals

AbstractThermalDispatchFormulation (no commitment, no forecast):

AbstractThermalUnitCommitment (commitment, no forecast):

AbstractThermalUnitCommitment + forecast attached — adds on top of commitment:

ThermalMultiStartUnitCommitment — multiple metas under the same constraint type:

Observed inconsistencies

Descriptive, not prescriptive — flagging for discussion, not proposing fixes:

1. Commitment coupling lives under different keys across device families.

   • Thermals: (ActivePowerVariableLimitsConstraint, …, "lb"/"ub") for both dispatch and UC, plus "on"/"off"/"ubon"/"uboff" for multi-start.
   • Loads: (ActivePowerVariableLimitsConstraint, …, "binary") — a meta string that exists nowhere on the thermal side.

2. Forecast + commitment are never folded into a single row. Thermal UC with forecast produces two separate rows (p ≤ pmax·u and p ≤ forecast_t · pmax) under different constraint types. Loads do the same. ThermalMultiStartUnitCommitment does fold commitment and startup/shutdown trajectories into a single row — but not forecast.

3. The meta-string vocabulary is ad-hoc. Thermals use "lb", "ub", "on", "off", "ubon", "uboff". Loads use "binary". Nothing enforces or documents the vocabulary; no registry of valid metas per constraint type.

4. Lower bounds are enforced three different ways.

   • JuMP variable bound (loads; thermal dispatch via add_range_constraints!)
   • Explicit constraint row with meta "lb" (thermal multi-start)
   • Expression-based ≥ 0 under the same "lb" meta (thermal multi-start with ActivePowerRangeExpressionLB)

   The ThermalMultiStart case reuses the "lb" meta for two semantically different rows (one on the variable, one on an expression), which would collide if both code paths ran for the same device.

5. Nameplate UB materialization is asymmetric. Thermals always create an ActivePowerVariableLimitsConstraint row. Loads push the nameplate into the JuMP variable's upper bound and only materialize a constraint row when commitment (PowerLoadInterruption) or a forecast is involved.