Phase change assumes a caloric equation of state that a mechanical EOS does not supply

[sbryngelson]

Split out from #1762, which centralized the mechanical equation of state. The caloric relations were
left alone deliberately; this records why, and what closing the gap requires.

What is left

src/common/m_phase_change.fpp builds four thermodynamic quantities inline from cvs, qvs,
qvps, isentrope_n and isentrope_B, each in one place inside s_infinite_ptg_relaxation_k:

sk(i)   = cvs(i)*log((TS**isentrope_n(i))/((pS + isentrope_B(i))**(isentrope_n(i) - 1))) + qvps(i)   ! entropy
hk(i)   = isentrope_n(i)*cvs(i)*TS + qvs(i)                                                          ! enthalpy
rhok(i) = f_sg_thermal(pS, TS, isentrope_n(i), isentrope_B(i), cvs(i))                               ! already an operator
ek(i)   = (pS + isentrope_n(i)*isentrope_B(i))/(pS + isentrope_B(i))*cvs(i)*TS + qvs(i)              ! e(p,T)

Only the thermal law was extracted (f_sg_thermal). The other three have a single call site each, so
extracting them today would be a one-line relation behind procedure boilerplate - net-negative, which
is why #1762 stopped here rather than finishing for symmetry.

Why this is a physics decision, not plumbing

They become worth extracting the moment a second equation of state needs them, and that is exactly
where the difficulty is. A Mie-Gruneisen or JWL EOS as normally written is mechanical:
p(rho, e) with no temperature, entropy or per-phase enthalpy at all. Nothing in the JWL parameter
set fixes a caloric equation of state; supplying one means adding a heat-capacity model and a
reference entropy that the published parameters do not constrain.

So phase change with such a fluid is not "make the operators generic". Either:

1. the EOS family carries a caloric extension the user must supply, and case_validator.py requires
   it before allowing phase_change with that fluid; or
2. phase_change is prohibited for mechanical-only EOS families outright.

Option 2 is likely right for a first cut, and it is a validator rule rather than solver code.

Suggested scope

• Decide 1 or 2 above; if 2, add the prohibition with a PHYSICS_DOCS entry explaining it.
• Only if 1: extract f_phase_entropy, f_phase_enthalpy, f_phase_energy_pT alongside
  f_sg_thermal in m_variables_conversion.fpp, taking coefficients rather than a fluid index like
  the rest of the operator surface, and give the caloric extension its own backend hook.

No behaviour should change either way. This blocks nothing in #1638 as long as the validator says
plainly which combinations are refused.