[Bug]: shared timestamp parsing overflows on UTC boundary offsets #6081

Preflight

• I searched existing issues and discussions for this behavior.
• This report is not an unpatched security vulnerability.
• The report and attachments contain no credentials or private/internal material.

Issue origin

Observed or reproduced in a real environment

LoopX version or commit

07eb7a1

Host or runtime surface

Not host-specific

LoopX area

Control plane (goals, todos, quota, scheduler, registry, runtime)

Problem

parse_timestamp catches ValueError only for datetime.fromisoformat, then converts aware values to UTC outside that guard. A syntactically valid offset timestamp near datetime.min or datetime.max can overflow during astimezone(timezone.utc). This shared parser is used by many control-plane paths, so a malformed persisted or supplied timestamp can abort its caller instead of being treated as invalid. The merged run-history fix in #3347 catches this only at the history consumer; other parse_timestamp callers remain exposed.

Minimal reproduction

From the repository root on commit 07eb7a1, run:

from loopx.control_plane.runtime.time import parse_timestamp
parse_timestamp("9999-12-31T23:59:59-14:00")

This raises OverflowError: date value out of range. The lower boundary 0001-01-01T00:00:00+14:00 reproduces the same exception.

Expected behavior

Timestamps whose UTC conversion falls outside datetime's representable range should be treated as invalid and return None, matching the parser's behavior for invalid ISO text.

Actual behavior

Both boundary examples raise OverflowError from astimezone(timezone.utc), escaping the shared parser. Callers without their own guard then fail while processing the timestamp.

Sanitized diagnostics

Reproduced locally with CPython 3.14.7 on commit 07eb7a1288.

Additional context

The existing chronology_key and history consumer in loopx/history.py already catch this exception locally, as does one expiry path in boundary_authority.py. The shared parser can handle it once for all callers. Related merged PR: #3347, which guards its history consumer but leaves the parser unchanged.