Deduplicate network-family constructor method pairs via the network-conditional helpers

Context

Many device constructors carry a duplicated construct_device! method pair per formulation: an AbstractActivePowerModel body and an AbstractNetworkModel body that differ only by the reactive-power wiring (variable creation + ReactivePowerBalance wiring in the argument stage, or one reactive-limits add_constraints! call in the model stage).

The designed mechanism to avoid this already exists in src/common_models/network_conditional.jl: _maybe_add_reactive_power_variables! and _maybe_add_reactive_power_constraints! (including the variable-typed form added in 8bb43f0), each with an AbstractActivePowerModel no-op twin, so a single AbstractNetworkModel-bound method serves both network families.

PR #190 (commit 8bb43f0) applied this to hydrogeneration_constructor.jl, collapsing all eight ModelConstructStage pairs (41 -> 33 constructor methods, ~280 duplicate lines removed), pinned by a container-schema parity test. This issue tracks the remaining sweep, prompted by review discussion in #190.

Remaining work

Files with AbstractActivePowerModel constructor references (rough pair-pattern signal):

• thermalgeneration_constructor.jl (largest: 17 APM references)
• load_constructor.jl (13)
• hydrogeneration_constructor.jl ArgumentConstructStage pairs (10 remaining; see blocker below)
• source_constructor.jl (4)
• hybridsystem_constructor.jl (4)
• renewablegeneration_constructor.jl (3)
• storage_constructor.jl (2)

shunt_constructor.jl is excluded: its remaining APM methods are intentional defensive no-ops for validation-bypass paths, not duplicates (see the convention question below).

Method (per file, established in the hydro pass)

1. Inventory every APM/ANM pair per formulation and stage; body-diff each pair.
2. Collapse ONLY pairs whose delta is exactly the shape a _maybe_* helper reproduces (reactive variable + balance wiring, or one reactive-limits constraint call). Anything else stays and gets documented.
3. Never branch on network_has_reactive_power with if; the no-op-dispatch helpers are the mechanism.
4. Freeze a container-schema parity test per file before refactoring (reactive containers present on ACP, absent on DCP); consider a full sorted constraint-key snapshot for stronger regression protection.
5. Test.detect_ambiguities must stay empty; deleting methods can surface latent ambiguities (see blocker).

Known blocker

Two hydro ArgumentConstructStage pairs (HydroWaterFactorModel turbine, HydroTurbineWaterFormulation) qualify textually but collapsing them creates dispatch ambiguities against a pre-existing overly broad D <: AbstractHydroDispatchFormulation, S <: AbstractActivePowerModel argument-stage method. That bound should be narrowed first.

Related convention question

The tree currently has two conventions for the validation-bypass case: shunt/tap keep defensive APM no-ops with explanatory comments, while SynchronousCondenserBasicDispatch (after #190) fails loudly at get_expression. Pick one convention as part of this sweep.

Start with src/common_models/network_conditional.jl and the completed hydro pass, then inventory the constructor pairs in thermalgeneration_constructor.jl, load_constructor.jl, source_constructor.jl, hybridsystem_constructor.jl, renewablegeneration_constructor.jl, storage_constructor.jl, and the remaining hydro argument-stage pairs. Add container-schema parity tests before each refactor and run Test.detect_ambiguities. Done means only helper-equivalent pairs are collapsed, the hydro dispatch bound is narrowed, and the validation-bypass convention is chosen and documented.