fix(lifecycle-guard): return a verdict when the home directory is unresolvable

[ruochu88s]

What does this PR do?

The lifecycle guard raises instead of returning a verdict when ~ cannot be
expanded, which aborts the whole terminal tool call:

RuntimeError: Could not determine home directory.
  File "cron/lifecycle_guard.py", line 174, in _resolve_terminal_script_path
    path = Path(candidate).expanduser()

Path.expanduser() raises RuntimeError, not OSError, so the surrounding
except OSError handlers do not catch it. Because this guard runs on every
terminal command, the result is not "command blocked" and not "command failed" —
it is the guard itself crashing for a command that has nothing to do with
gateway lifecycle.

Encountered in real use while running an unrelated git add + python
pipeline.

Reproduction

With HOME / USERPROFILE / HOMEDRIVE / HOMEPATH unset:

'echo hello'         -> verdict=False
'bash ~/script.sh'   -> RAISED RuntimeError: Could not determine home directory.
'sh ~/nested/run.sh' -> RAISED RuntimeError: Could not determine home directory.
'bash ./local.sh'    -> verdict=False

Two conditions must coincide:

1. the command references a ~/-relative script, and
2. the environment lacks the home variables.

Commands without ~ never reach expanduser() and are unaffected.

Environments that land in this state: processes started with env -i, service
accounts, stripped containers, and CI runners. This repo's own
scripts/run_tests.sh has needed fixes for the same class of problem, since
env -i drops USERPROFILE on Windows.

The fix

• Catch RuntimeError around expanduser() and fall back to the literal path.
  An unexpanded ~/x.sh simply will not be readable, and the caller already
  handles unreadable scripts.
• Also guard Path.cwd(), so a deleted or inaccessible working directory cannot
  break the scan either.

Detection strength is unchanged. With HOME absent, a gateway lifecycle command
is still caught, and a relative script's body is still read and scanned — the
degradation is confined to ~ expansion.

How was it tested?

New: tests/cron/test_lifecycle_guard_unresolvable_home.py — 9 passing.

The no-HOME fixture asserts that Path('~').expanduser() really does raise
before running the case, so the tests cannot silently pass on a platform where
it resolves.

Cases: three ~-script shapes return a verdict instead of raising; unrelated
commands unaffected; a dangerous command is still detected; a relative script
body is still scanned; baseline behaviour with HOME present is unchanged
(including scanning a tilde script's body); a deleted cwd does not raise.

9 passed, 1 warning in 0.77s

Fault injection. Restoring the bare expanduser() call turns 4 assertions
red; the fix returns 9/9:

--- with the fix
    9 passed, 1 warning in 0.77s
--- fault injection: revert to bare expanduser()
    FAILED test_tilde_script_does_not_raise_without_home[bash ~/a.sh && echo done]
    FAILED test_missing_cwd_does_not_raise
    4 failed, 5 passed, 1 warning in 0.67s

Relationship to existing PRs (not a duplicate)

Two open PRs touch the same class of defect. Both were checked against the
current main:

• fix(cron): catch RuntimeError from Path.expanduser() in lifecycle guard #56517 — fix(cron): catch RuntimeError from Path.expanduser() in
  lifecycle guard. Same file, different function and different call path:
  it guards _read_script_for_scanning / _resolve_script_path, reached when a
  cron job's script field is scanned. On current main those symbols no
  longer exist under those names, so that patch does not cover the terminal
  path. This PR guards _resolve_terminal_script_path, reached for every
  terminal command that references a script.
• refactor: sweep remaining bare expanduser() to safe_expanduser() (depends on #41870) #41881 — sweep remaining bare expanduser() to safe_expanduser(). Its 39
  changed files do not include cron/lifecycle_guard.py, so the sweep leaves
  this call site untouched.

If safe_expanduser() from #41870/#41881 lands first, this change should be
rewritten to call it instead of the local try/except — the fallback semantics
are identical, and I am happy to rebase onto that helper. The test file stays
valid either way, since it asserts observable behaviour (returns a verdict,
detection unchanged) rather than the mechanism.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactor / internal change

Checklist

• I have searched existing issues and PRs to avoid duplicates (see
  "Relationship to existing PRs" above — fix(cron): catch RuntimeError from Path.expanduser() in lifecycle guard #56517 and refactor: sweep remaining bare expanduser() to safe_expanduser() (depends on #41870) #41881 both checked)
• My code follows the project's style guidelines
• I have added tests that prove my fix is effective
• All new and existing tests pass locally
• I have updated documentation as needed

Platform

• Windows
• macOS
• Linux

Reproduced and verified on Windows 10, but the defect is not
Windows-specific: Path.expanduser() raises the same RuntimeError on POSIX
when HOME is unset and the uid has no passwd entry. On Windows the trigger is
simply easier to hit, because both USERPROFILE and the
HOMEDRIVE+HOMEPATH pair must be present.

[kshitijk4poor]

Closing as superseded by #80258, which fixes this whole bug class architecturally rather than per-callsite: path candidates are sanitized once at the ingestion boundary (NUL/empty/unexpandable tokens rejected before any OS call), text from any read_remote_script callback is sanitized at the recursion boundary (NUL = binary = nothing to scan; >1 MiB = fail closed), the remote fallback read is bounded at the source (head -c, so oversized binaries never cross the wire), and the public guard is total by construction — an unexpected walk failure logs and falls back to the direct-scan verdict instead of breaking every terminal command.

Your report and fix targeted a real member of this class — thank you. The per-callsite patches kept leaving sibling frames exposed (#76762 → #77703 → #77780 → #78256 each crashed one frame away from the previous fix), which is why we went with the boundary fix instead of merging the fragments individually. #80258 carries regression tests for the NUL-path, binary-callback, oversized-read, unset-HOME, and walk-crash cases plus an adversarial never-raises sweep.