fix_uninitialized RSP L on photo restart, bug found by Mami Dekka

[Debraheem]

@mami-deka discovered an issue in RSP's photo restart where on one of her clusters, L was being set to a small positive number, since it was uninitialized, and this lead to the call to calculate the KH_timescale (which asks for it asks for s% L(1), and divides by it) to produce a large infinite number from overflow, ultimately crashing her mesa run.

from @mami-deka:

I am using MESA r23.05.1 for RSP and recently set up on a new cluster called Newton. Fresh runs work correctly on the Newton: ./rn produces physically sensible output and writes photos. However, restarting from an existing photo with ./re fails immediately.

On the old cluster, the restart behaves normally. After read restart_photo, it prints the expected RSP restart block:

net name [o18_and_ne22.net]
RSP_flag T
v_flag T
tau_factor
kap_option
OMP_NUM_THREADS

On Newton, the same restart instead prints only:

read restart_photo
s% kh_timescale Infinity
s% cgrav(1) 6.6743000000000004D-08
mstar ...
radius ...
luminosity ~6.9D-310

She also discovered the solution to this issue, which was to recalculate L upon restart.

[Debraheem]

One might ask why we don't just store and read L when the rsp flag is set. That might be a good idea as well, although it would not be providing the photos any new information they don't already have.

I can think of other fixes as well, like raising the floor on L for Kh_timescale to a large positive number instead of 0d0. But L could still then be undefined upon photo restart.