Fix rescoup master-group guide-rate distribution

[hakonhagland]

Builds on #7067.

Fixes a reservoir-coupling bug where a master group was excluded from its parent's guide-rate distribution, causing the slave's production and injection to oscillate between zero and the well-rate limits on every substep.

Problem

• A reservoir-coupling master group that has its own GCONPROD rate limit and is available for higher-level group control (GCONPROD item 8 RESPOND_TO_PARENT = YES) was wrongly excluded from its parent's guide-rate distribution.
• The group-controlled-wells count (GCW) that gates this participation was derived from the production control mode. But a master group carries an individual (ORAT) control mode purely as a marker for communicating its computed target to the slave, so the control mode does not reflect whether the group should participate.
• As a result each such group was allotted close to the full parent target instead of its guide-rate share. The over-allocation then fed back through the FIELD target reduction on the next sync step, producing a substep production/injection oscillation — field oil rate alternating between zero and the well-rate limits every step.

Fix

• Introduce a per-master-group effective GCW on ReservoirCouplingMaster (effectiveGCW / setEffectiveGCW / resetEffectiveGCW), decoupled from the control mode and reset at the start of each sync step.
• Add an eligibility predicate GroupStateHelper::isMasterGroupEligibleForGuideRate (item 8 = YES) and apply it at the three sites that gate participation: the guide-rate sum (FractionCalculator::guideRateSum), the GCW aggregation toward the parent, and the target-reduction individual_control decision (updateGroupTargetReductionRecursive_). The GCW aggregation site is what was missing at the intermediate hierarchy levels.
• Read the effective GCW for master groups in GroupStateHelper::updateGroupControlledWellsRecursive_ (via the new getMasterGroupEffectiveGCW_ helper) instead of deriving it from the control mode.
• Populate the effective GCW in RescoupConstraintsCalculator: reset each sync step (participating groups default to 1), set 0 for inactive slaves' master groups, and set 0 for groups capped at their slave's reported potential during cap-and-redistribute.
• Eligibility is necessary but not sufficient: a capped or inactive-slave group is eligible yet has effective GCW = 0, so it drops out of the guide-rate sum and its rate is subtracted as a parent target reduction — which is exactly how its shortfall is redistributed to its siblings.
• The predicate returns false for non-master groups, so the standard (non-coupled) guide-rate path is unchanged.

Validation

• The substep oscillation is removed across the bulk of the rc_m1 run: the field now produces steadily near its deliverability instead of bang-banging between zero and the well limits.
• Cumulative field oil production rises, closing roughly half of the gap to the reference solution (field-level FOPT gap improves from about −47% to −24%); the remaining oil and gas gaps are the injection-side reinjection cascade, handled in separate follow-up work.

Known follow-up (out of scope)

• A narrower residual oscillation remains late in rc_m1 once a slave depletes to zero and its share is redistributed onto an over-asked sibling (the cap-and-redistribute path). It is milder than before and not a regression — the pre-fix run oscillated for the entire run, whereas this fix makes the bulk of the run smooth. It is tracked as a separate follow-up.

[hakonhagland]

Putting this in draft mode until #7067 has been merged.

[hakonhagland]

jenkins build this serial please

[hakonhagland]

jenkins build this serial please

[hakonhagland]

jenkins build this serial please