fix: lazy + crash-safe epoch formatting in eclipse-check debug log

[TobiasEdman]

Problem

CentralBody.blocks_sun() formats the actor and epoch into an f-string on every timestep:

logger.debug(f"Checking whether {actor} is in eclipse at {t}.")

On some pykep builds — observed with conda-forge pykep 2.6.4 (osx-arm64, Python 3.11) — str(pk.epoch) raises RuntimeError: bad lexical cast for epochs at exact minute boundaries:

>>> str(pykep.epoch(60.0 / 86400.0))
RuntimeError: bad lexical cast: source type value could not be interpreted as target
# 59.999999 s and 60.000001 s both format fine — only the exact boundary fails

Since any simulation with power devices calls the eclipse check each advance_time(), every such simulation crashes at its first minute boundary regardless of log level — the f-string evaluates eagerly even when no DEBUG handler is active.

Fix

• Use logger.opt(lazy=True) with callables, so formatting only happens when a DEBUG record is actually emitted (also removes per-timestep string formatting from the hot path).
• Format the epoch through a _safe_epoch_str() fallback (mjd2000 representation) so logging can never crash the simulation even at DEBUG level.

The underlying pykep formatting bug is being reported upstream separately; this change makes PASEOS robust against it either way.

Verification

• paseos/tests/: 32 passed, 1 failure in thermal_model_test.py which fails identically on clean master (pre-existing, unrelated — numeric assertion).
• Before the fix, power_test.py::test_power_charging crashed with the lexical-cast error on the affected pykep build; it passes after.
• 90-minute two-shell scenario (300 km actor, power devices, 60 s steps) runs clean without workarounds.

Environment: macOS arm64, Python 3.11, conda-forge pykep 2.6.4, paseos master.

Co-authored with Claude (Anthropic) during a constellation-design study that uses PASEOS for power/eclipse validation.

[gomezzz]

Hi @TobiasEdman !

Our CI setup has grown a bit stale, it seems. I have made some small PRs to fix it (and a small bugfix along the way).

I don't want to mess with your current activities but to enable having functional tests, I would suggest to merge them. This should enable the CI on this PR to pass.

The PRs are here:
#217 <- moving to modern pyproject.toml setup
#218 <- replace black/flake8 with ruff
#221 <- switch CI and default install to uv
#220 <- small fix that could lead to crashes and test failures in real-time mode

Would you like to review them? Otherwise, from my end, I can also go ahead and merge them. My priority is mostly to have a working CI set up to quickly see, if small PRs like this one pass to be able to approve and merge them swiftly.