Fix extendable thermal handling in the UCBlock expansion path

[dmeoli]

Problem

On a pypsa-eur instance with extendable CCGTs, converting with
capacity_expansion_ucblock=True gave an objective +426% above the PyPSA
reference, while the InvestmentBlock path was within 0.06%.

The UCBlock path normalizes an extendable unit's MaxPower to a per-module
value (a design variable is meant to carry the MW), but the design fields
(InvestmentCost / MaxCapacityDesign) are only injected for intermittent
and battery units. Extendable thermals were left normalized with no design
variable, i.e. modeled as 1 MW plants. UCBlock cannot represent continuous
thermal expansion anyway: the commitment u_t is binary and a continuous
design would multiply it in the max-power constraint (p_t ≤ κ·MaxPower·u_t),
making the model bilinear.

A second, latent issue: StartUpCost and ConstTerm were passed through as
absolute per-generator values while every other scaled field is normalized
per module when p_nom_extendable. Under Scale/InvestmentBlock scaling they
were multiplied by the capacity again (double-counting), affecting both paths.

Fix

• Extendable thermal in the UCBlock path → raise a ValueError: the
  converter cannot represent it and does not silently alter the model. The
  message asks to either set p_nom_extendable=False on the unit or use the
  InvestmentBlock path (capacity_expansion_ucblock=False).
• StartUpCost / ConstTerm → normalized per module when
  p_nom_extendable, like the other scaled fields.

Validation

• pypsa-eur instance, UCBlock path: the conversion now fails fast with the
  error above instead of returning a +426% objective.
• test_ucblock 15/15 pass (networks without extendable thermals are
  unaffected).

Not covered

QuadTerm (quadratic marginal cost) is structurally incompatible with the
fleet/Scale semantics for thermals (S·q·p² ≠ q·(S·p)²) and cannot be fixed
by normalization; it is 0 in the tested instances. A follow-up could warn when
a nonzero quadratic cost meets an extendable thermal.

[AlessandroPampado99]

Non trovo molto utile tutta questa cosa... Mi sembra come mettere una pezza. Potrebbe essere più utile rompere il loop e dare errore in caso, che dici? Perché tanto non avremmo comunque una corrispondenza in fo e uno user generico non capirebbe

[AlessandroPampado99]

Aggiungere poi il costo per far tornare i conti in quel modo credo che prima o poi farà rompere qualcosa. Le correzioni in transformation_config vanno bene invece