fix(cli): guard local-backend cwd resolution against a deleted CWD

[Dusk1e]

What & Why

load_cli_config() set terminal_config["cwd"] = os.getcwd() for the local
backend with no guard. When the launch directory is deleted out from under the
process, os.getcwd() raises FileNotFoundError, crashing CLI/TUI startup —
and the gateway's lazy import of cli.py — before anything else runs.

The fix reuses the existing tools.terminal_tool._safe_getcwd() helper, which
falls back to TERMINAL_CWD then the home directory. This is the same archetype
already used in terminal_tool for this exact failure (commit ad69d3edc,
"fix(terminal): guard os.getcwd() against a deleted CWD"), so the resolved cwd
stays consistent with the backend that consumes it.

How to test

Repro (before the fix): patch os.getcwd to raise FileNotFoundError and call
cli.load_cli_config() — it crashes at the local-backend cwd line. After the
fix it resolves to TERMINAL_CWD, then home.

Added regression tests in tests/cli/test_cwd_env_respect.py (TestDeletedCwd)
that exercise the real load_cli_config() with a deleted CWD. They fail without
the fix and pass with it.

[teknium1]

Thanks for the focused regression fix. The premise remains present on current main: cli.py:604 calls os.getcwd() directly for the local backend, while the existing tools/terminal_tool.py:1196-1207 helper already provides the intended deleted-CWD fallback. The PR reuses that helper and its added tests invoke the real cli.load_cli_config() path for both fallback branches.

The TUI slash worker imports cli at tui_gateway/slash_worker.py:30-31, so protecting the shared loader also covers that startup path. The target block and test file have not materially moved, making this a high-confidence mechanical salvage.

Automated hermes-sweeper review.