fix(cron): catch RuntimeError from Path.expanduser() in lifecycle guard

[srojk34]

Summary

cron/lifecycle_guard.py::_resolve_script_path calls Path(script_path).expanduser() to resolve a cron job's script path before scanning it for gateway-lifecycle commands (check_gateway_lifecycle, enforced in cron.jobs.create_job — reachable via both hermes cron create and the agent's cronjob model tool directly).

Path.expanduser() raises RuntimeError (not OSError) for a ~user-shaped path with no matching system user:

>>> from pathlib import Path
>>> Path('~nonexistentuser12345/foo').expanduser()
RuntimeError: Can't determine home directory for 'nonexistentuser12345'

_read_script_for_scanning's except OSError: doesn't catch this, so an LLM-authored script value that happens to start with ~someuser/... (a plausible thing for an agent to produce — the same trigger shape already fixed for agent/subdirectory_hints.py in #c126a99fc, "LLMs use ~ for 'approximately'" or a guessed/malformed path) crashes cron job creation with an unhandled RuntimeError instead of the intended graceful GatewayLifecycleBlocked/pass-through behavior the module is designed around.

Fix

Add RuntimeError to the caught exceptions in _read_script_for_scanning, mirroring the exact fix already applied to agent/subdirectory_hints.py's three Path.expanduser()/Path.home() call sites in #c126a99fc.

Test plan

• New regression test test_tilde_unknown_user_script_does_not_crash — confirmed it fails with an uncaught RuntimeError on the pre-fix code (via git stash) and passes after the fix
• pytest tests/hermes_cli/test_gateway_restart_loop.py -q — 66 passed
• ruff check on all changed files — clean
• Checked for competitors: PR refactor: sweep remaining bare expanduser() to safe_expanduser() (depends on #41870) #41881 ("sweep remaining bare expanduser() to safe_expanduser()") is a 2-file refactor (cron/jobs.py, cron/scheduler.py) that does not include cron/lifecycle_guard.py — confirmed via gh pr view --json files. No overlap.

[teknium1]

Thanks for isolating the creation-time failure and adding a targeted regression test. The premise is confirmed on current main: cron/lifecycle_guard.py:89 expands the supplied script path while :108 catches only OSError; cron/jobs.py:1158-1159 invokes that guard from the shared creation chokepoint.

Problems

• The same accepted script value still reaches an unguarded Path(script_path).expanduser() in cron/scheduler.py:2050, before _run_job_script's error-to-result handling. With this PR, a ~unknown-user/... script no longer fails at creation but can still raise when the job fires.

Suggested changes

• Convert that scheduler-side RuntimeError into the normal failed-script result and cover the runtime path with the same unknown-user tilde input.
• Add a create_job-level assertion for the new creation-time contract, in addition to the direct guard test.

Automated hermes-sweeper review.

[teknium1]

Please handle the same ~unknown-user input in cron/scheduler.py:2050: _run_job_script() calls Path(script_path).expanduser() before its exception-to-result handling. This catch now permits creation, but the scheduled run can still raise RuntimeError instead of returning the documented failed-script tuple.