feat(model): allow {0,1} bounds for binaries in add_variables

[FBumann]

Note

The following content was generated by AI.

Summary

Refs #776 (the follow-up requested in the issue comment). Stacked on #777 — review/merge that first; the base will retarget to master once #777 lands.

add_variables(binary=True, ...) previously raised on any lower/upper, so binary bounds could only be set via the .lower/.upper setters after creation. This allows passing them directly at construction, as long as every bound value is 0 or 1.

# now works:
m.add_variables(binary=True, upper=pd.Series([1, 1, 0, 0]), coords=[t], name="x")  # mask out t=2,3
m.add_variables(binary=True, lower=1, coords=[t], name="on")                        # force on

Behavior

• Unset bounds still default to 0 / 1.
• Provided bounds are validated after broadcasting: any value other than 0 or 1 (masked/NaN slots ignored) raises ValueError: Binary variable {lower,upper} bounds must be 0 or 1.
• Combined with fix(io): write LP bounds for tightened binary variables #777, a binary constructed with tightened bounds round-trips identically through io_api="direct" and io_api="lp".

Note on netcdf / backward compat

add_variables only validates inputs — no downstream code changed. read_netcdf rebuilds variables directly from stored data (bypassing add_variables), but no load-time normalization is needed: 0/1 binary defaulting and the current netcdf format both landed in v0.2, so any file today's read_netcdf can parse already stores binaries as [0,1]. Older files with inf-bound binaries predate the format and aren't loadable anyway.

Tests

• test_variable_assignment_binary_with_bounds — per-element upper and scalar lower=1 at construction.
• test_variable_assignment_binary_fractional_bound_error — fractional bound raises.
• Existing test_variable_assignment_binary_with_error (lower=-2) still raises under the new validation.