Pre-solve feasibility check for balance groups and coupling constraints (fail usefully, not opaquely)

[Flix6x]

Context

Since the built-in storage fallback scheduler was retired (#2252), an infeasible storage problem fails with its failure reason. For contradictions within a single device, #2252 also added pre-solve validation (validate_power_constraints, plus a fix so stock-less devices no longer disable validation for subsequent devices), so those fail with a clear per-time-step message.

Problem

Contradictions across devices are still reported only as a bare InfeasibleProblemException carrying the solver's termination string. Typical cases (cf. the flex-models of #2323 and #2329):

• An internal node (commodity without a grid connection, Balance internal commodity nodes (heat/steam networks) via first-class balance groups #2289) whose devices must balance each other at every time step, but whose members can only flow in one direction (e.g. only producers, or a PV device plus a converter port that can only consume at a fixed ratio to another commodity's flow).
• Coupling groups (Combined Heat and Power (CHP) #2218) with fixed flow ratios that, combined with directional capacities or whole-window zero capacities (hard per Keep explicit zero directional capacity hard under relax-constraints #2345 and Keep device capacities hard unless relaxation is asked for #2398), admit no feasible flow at some time step.
• A group power capacity that contradicts the hard bounds of its members (e.g. the group's hard power-capacity below the sum of members' minimum forced flows).

Per-device column checks cannot see these — they need a check over each balance group / coupling group as a whole.

Proposal

Add a pre-solve feasibility check per balance group and coupling group, e.g. per time step:

• sum of members' feasible flow intervals (after applying coupling ratios) must admit 0 (for internal nodes) or intersect the group's/site's hard capacity interval;
• report violations through the existing create_constraint_violations_message machinery, naming the group and time steps, like the per-device validation added in Feat/retire fallback scheduler #2252.

This is interval arithmetic over already-built constraint frames, so it should stay cheap relative to the solve.

Why 1.1.0

Not release-blocking for v1.0.0: behaviour is correct (the problem is infeasible); this is about the difference between failing usefully and failing opaquely, which grew in importance now that no fallback schedule cushions such failures.