One-way setting of `max_years_for_timestep`

**Describe the bug**
When setting `max_years_for_timestep` to a positive number, it can never be meaningfully set back to zero mid-run (i.e., in `run_star_extras.f90`).

**To Reproduce**
Steps to reproduce the behavior:
1. Set `max_years_for_timestep` to a positive value in the inlist or dynamically in `run_star_extras.f90`
2. Later, dynamically set `max_years_for_timestep` to zero

**Expected behavior**
The timestep should be limited accordingly until `max_years_for_timestep` is zeroed, at which point the limiter should no longer function.

**Version**
- MESA version 26.04.1 (and probably earlier versions)
- SDK version: x86_64-linux-26.3.2
- OS: Rocky Linux

**Additional context**
I think the bug is in the function `pick_next_timestep` in `evolve.f90` (line 2067 in the version I'm looking at now). Here's the relevant code:
```fortran
if (s% max_years_for_timestep > 0) then
max_timestep = secyer*s% max_years_for_timestep
if (s% max_timestep > 0 .and. s% max_timestep < max_timestep) &
max_timestep = s% max_timestep
else
max_timestep = s% max_timestep
end if
```
Crucially, the `if` only fires on positive values, so a change to 0 (or a negative value, for that matter) is never picked up.

A workaround is to just set `max_timestep` directly to 0 in addition to setting `max_years_for_timestep` to 0, or to just rely on `max_timestep` directly. I'm not sure if this has knock-on effects for `hi_T_max_years_for_timestep`.

I can probably fix this, but can't get to it at the moment, so I wanted to at least record the bug here.