Add enable_ront: regulated transformer (rONT) as an LV voltage measure (#377)

[nader-00]

Description

Adds an opt-in LV voltage-issue reinforcement measure: converting an LV
station's standard transformer to a regelbarer Ortsnetztransformator (rONT,
regulated distribution transformer) instead of reinforcing/disconnecting LV
lines, for grids where a bounded voltage-control range at the station is
sufficient to resolve all LV voltage issues.

Part of the broader effort in #377 (add/improve grid reinforcement methods).

Problem

Today, LV voltage issues are always solved by splitting/reinforcing LV
feeders (reinforce_lines_voltage_issues), even in cases where the actual
spread of LV voltage deviations across the grid is small enough that a
regulated transformer at the station — a real, commonly used piece of
equipment in German LV grids — would resolve the issue without touching a
single line.

Solution

• New enable_ront: bool = False parameter on reinforce_grid(). When
  enabled, for every LV grid with voltage issues, before falling back to line
  reinforcement, checks whether a regulated transformer with a bounded
  control range (lv_grid_ront_feasible()) can resolve all voltage issues at
  that grid — if so, converts the station's transformer to its rONT
  equivalent (reinforce_lv_grid_ront_voltage_issues()) instead of touching
  lines.
• Model: rONT is treated as electrically identical to the standard
  transformer it replaces (same s_nom/r_pu/x_pu) — the voltage-
  regulating behaviour is modelled as a widened, bounded allowed-voltage
  window around the transformer's own unregulated secondary voltage
  (v_unreg(t)), evaluated in _lv_allowed_voltage_limits(), rather than by
  simulating an actual tap-changer in the power flow. This is a deliberate
  simplification (Option A from the design discussion) — see Caveats below.
• Feasibility check (lv_grid_ront_feasible()): the single source of
  truth used both by the reinforcement guard and by the RONT-aware final
  check, so "a RONT was installed" and "the final +/-10% band check passes"
  are structurally guaranteed to agree, not just empirically.
• Final check: the existing global +/-10% voltage check
  (allowed_voltage_limits(split_voltage_band=False)) excludes (does not
  silently pass) buses belonging to a feasible-RONT grid, using the same
  lv_grid_ront_feasible() function — everything else keeps the untouched,
  hard +/-10% band as a backstop.
• New equipment rows: one " RONT"-suffixed variant per standard LV
  transformer size in equipment-parameters_LV_transformers.csv, impedance-
  identical to its base type (is_ront()/ront_type_name()/
  standard_type_name() helpers in tools.py).
• New config: [grid_expansion_ront].ront_voltage_range = 0.10 and
  [costs_transformers].ront_surcharge = 20 (both sourced, see Config
  values below).

Two additional, incidental fixes found during integration testing

1. Duplicate-transformer bug: _reinforce_station_overloading()'s
   "second transformer of the same kind" clone branch copied the RONT-tagged
   type_info verbatim onto a new transformer meant to resolve an
   independent overload — meaning a RONT station could end up with two
   RONT-tagged transformers instead of one RONT (voltage) plus one correctly
   typed standard transformer (overload). Fixed via an is_ront() check +
   standard_type_name() reassignment before the clone is renamed. The
   invariant is "no station has more than one RONT-tagged transformer", not
   "no station has more than one transformer" — a RONT station legitimately
   can gain a second, standard transformer for an independent overload.
2. Transformer cost bug (unrelated to the above, found during cost
   validation): grid_expansion_costs() only ever costed transformers with
   equipment_changes["change"] == "added", never "changed". RONT
   conversions are logged as "changed" (the transformer itself is not
   replaced, only its type_info), so RONT's ront_surcharge was silently
   never costed (always 0 kEUR). Fixed by extending the costable-transformer
   filter to include "changed" entries (excluding any later "removed"),
   mirroring how "changed" lines are already costed unconditionally.

Config values (sourced)

• ront_voltage_range = 0.10: FNN-Hinweis "Regelbarer Ortsnetztransformator
  (rONT) — Einsatz in Netzplanung und Netzbetrieb" (2016), sections
  5.9.1/5.9.2 — the network-planning criterion uses +/-10% (9 taps, 2.5%
  step); market products and all five practical examples in annex B confirm
  +/-4 x 2.5%.
• ront_surcharge = 20 kEUR: same source, section 5.8.1 — names the cost
  components (procurement, installation incl. sensors/control electronics,
  documentation) but no absolute figures; the value itself is a placeholder,
  operator- and product-specific, and should be adapted per use case.

Caveats (idealisation, called out explicitly)

• Real rONTs are stepped (2.5% per tap) with a control bandwidth/dead-band of
  typically ~4% (1.6x the tap step, FNN section 5.5.2) before the regulator
  switches. This PR's ref(t) model is continuous and dead-band-free — an
  optimistic idealisation relative to any real device, in addition to the
  general limitation that no actual tap-changer is simulated in the power
  flow.
• rONT cannot solve overload/thermal problems (FNN 2016, section 7/5.3) —
  this PR only ever uses it for voltage issues; an independent overload at
  the same station is still resolved by adding a correctly-typed standard
  transformer (see the duplicate-transformer fix above).
• Empirical benefit magnitude, for context: FNN annex B reports rONT cost
  ratios of 1:2.5 to 1:6-7 versus conventional expansion in real projects
  (~28% savings). Our own validation sample (33 known voltage-driven LV
  grids across 7 real networks) shows a comparable order of magnitude
  (status-quo 2573.0 kEUR -> RONT 1297.36 kEUR total, ~50%), though our flat,
  size- and cross-section-independent line cost model likely understates the
  conventional alternative rather than overstating it.

Validation

• Full unit test suite for the touched modules: 61 passed.
• Regression: enable_ront=False confirmed bit-identical to dev (pickled
  transformers_df, topology_lines_df, equipment_changes,
  grid_expansion_costs, compared via pandas.testing.assert_frame_equal),
  re-checked after every code change.
• Integration across all 33 known voltage-driven LV grids in 7 real networks
  (excluding one grid with a known, unrelated non-convergence issue): 33/33
  resolved via RONT, 0/33 residual violations against the final +/-10% check,
  7/7 networks without a ValueError, 0 stations with more than one
  RONT-tagged transformer, 33/33 grids with equal-or-fewer reinforcement
  measures than the status quo.

Related, but independent work

• PR Add alternative grid reinforcement methods (grid separation, switch balancing) #340 implements grid separation, switch balancing and feeder splitting
  from [FEATURE] Add grid reinforcement methods #377 — does not touch RONT, reinforce_grid.py,
  check_tech_constraints.py or tools.py at all (verified against its own
  merge-base). No overlap.
• PR Improve default voltage-issue and LV grid separation reinforcement measures #391 (undersized-cable upgrade before the 2/3 feeder split, transformer
  type_info cost fix for separate_lv_grid()) is unrelated: it fixes a
  type_info=None data bug on transformers added by separate_lv_grid()
  (an opt-in, whole-station-separation path unrelated to RONT), while this PR
  fixes a separate bug — change=="changed" transformers never being costed
  at all. Independent bugs, independent code paths, no dependency either way
  (is_ront(None) returns False rather than raising, and enable_ront is
  a reinforce_grid()-only parameter, never reaching separate_lv_grid()).

Type of change

• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue) — the two incidental
  fixes described above

Checklist:

• New and adjusted code is formatted using the pre-commit hooks
• New and adjusted code includes type hinting now
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• The Read the Docs documentation is compiling correctly
• If new packages are needed, I added them to setup.py etc.
• I have added new features to the corresponding whatsnew file