Resolved config records step caps as 0.0 when they were armed at the zalmoxis defaults

[timlichtenberg]

On the zalmoxis interior stack a configured 0.0 for the three Aragog step caps does not mean "no cap", it means "use the zalmoxis default". The written config, the schema default, and the resolved init_coupler.toml all show 0.0, so every artefact a reader can inspect states the opposite of what the solver received.

_resolve_step_cap in src/proteus/interior_energetics/aragog.py:196:

if cap < 0.0:
    return 0.0
if cap == 0.0 and is_zalmoxis:
    return zalmoxis_default
return cap

with _ZALMOXIS_DEFAULT_PHI_STEP_CAP = 0.1, _ZALMOXIS_DEFAULT_TEMPERATURE_STEP_CAP = 100.0, _ZALMOXIS_DEFAULT_ENTROPY_STEP_CAP = 100.0. Only -1.0 disables. The promotion is deliberate and the docstring explains why; the problem is that nothing downstream records that it happened.

Two consequences.

The resolved configuration is misleading. init_coupler.toml is the artefact written to preserve what a run was actually given, and for these three fields it preserves the pre-resolution value. A run whose init_coupler.toml reads phi_step_cap = 0.0 ran with a 0.1 cap armed. Anyone reading that file to reconstruct a run, or diffing two runs' resolved configs to explain why they behave differently, gets the wrong answer with no indication.

The same config text means different physics either side of the change that introduced the promotion. Two runs of the same file, one before and one after, differ in whether the caps are armed, and for a case near the phase boundary that is the difference between solidifying and stalling. Runs recorded before it cannot be reproduced from their own configs on current code.

Suggested fix, in order of preference:

1. Write the resolved value into init_coupler.toml, so the file states what the solver got. This is the one that matters.
2. Log at INFO on the promotion, naming the field, the configured value, the value used, and that -1.0 is the way to disable.
3. Consider whether 0.0 is the right spelling for "take the default" when the same field uses -1.0 for "off" and a positive number for "this value"; a three-way meaning across two sentinels is easy to misread, and the schema docstring for the field does not say that 0.0 is promoted.

Concretely, this cost a day of investigation. A run stalling at the phase boundary was diagnosed against a resolved config showing all three caps at 0.0, which ruled the caps out. They were the cause.