EMS-level FlowCommitments generate no coupling constraint in device_scheduler #2326

Observed in #2325

ems_flow_commitment_equalities in linear_optimization.py returns open bounds:

return (
    None,
    m.commitment_quantity[c, j] + m.commitment_downwards_deviation[c] + m.commitment_upwards_deviation[c]
    - sum(m.ems_power[d, j] for d in devices),
    None,
)

A (None, expr, None) ranged constraint has no binding side, so Pyomo emits nothing: an EMS-level FlowCommitment (no device column, no commodity filter — or a commodity filter matching all devices) is silently dropped from the model. Its deviation variables remain in the objective unconstrained, so a priced EMS-level flow commitment yields an unbounded model (HiGHS reports infeasibleOrUnbounded).

The StorageScheduler always builds flow commitments with a device or commodity scope, so production schedules are unaffected. But direct device_scheduler callers following the docstring ("Commitments are on an EMS level by default") hit this — encountered while writing test_stock_scoped_commitment_binds_group_stock in #2325.

Proposal

The bounds should presumably mirror grouped_commitment_equalities:

0 if "upwards deviation price" in commitments[c].columns else None,
...,
0 if "downwards deviation price" in commitments[c].columns else None,

plus a regression test with a priced EMS-level FlowCommitment. Checked that neither #2291 nor #2283 (the other open scheduler PRs) touches this.