OPAL/SCVH and Free_EOS fallback to HELM

Please see this thread on the mailing-list initially raised by Natasha:
https://lists.mesastar.org/pipermail/mesa-users/2026-May/015873.html

She highlights two regions of concern

In the low density temperature regime, the mean molecular weight and likely electron fraction returned by the eos is that of an ionized gas, which is unphysical. This is likely because the tabulated eos table files (the data files themselves) for Free_EOS and OPAL_SCVH in MESA fall back to HELM in their tabulation, and return :

mu = 0.66667
log_free_e = -99.00000

The Free EOS table floor is logT = 3, at and below which HELM values are tabulated
The same is true for the SCVH routines below the logP = -0.6 boundary (logRho ~ 10 -11 ish) below which HELM values are tabulated in the table.

These data tables get generated through MESA, so it looks like MESA is falling back to HELM before the table edge routines can activate for SCVH. Since the blend is something like:

```
if (logRho >= logRho5) then
pure_opal_scvh
else if (logRho > logRho6) then
blend
else
pure_helm
end if
```
with

```
logRho5 = -9.0d0
logRho6 = -9.99d0
```

Start with the linked mailing-list thread and inspect the Free_EOS and OPAL_SCVH tabulated data generation, especially the HELM fallback around the stated logT, logP, and logRho boundaries. Compare the table values and fallback conditions with the table-edge routines; done means low-density results no longer return the unphysical HELM values where those routines should apply.

Written by the indexing model from the issue text.