fix(cli): restore session cwd on mid-chat /resume and /sessions

[Dusk1e]

What & Why

A startup hermes -c / --resume correctly relaunches a session in the
directory it was started from (#38562). The same guarantee was missing for
the interactive /resume and /sessions <id> commands.

_restore_session_cwd() was only wired into the startup resume paths, so a
mid-conversation /resume loaded the transcript but left the process and
TERMINAL_CWD pointing at wherever the user happened to be. As a result the
terminal and execute_code tools — and all relative-path resolution — ran
against the wrong project, with a real risk of writes landing in the wrong
repository.

Change

_handle_resume_command() now calls _restore_session_cwd(session_meta)
after the session is loaded, matching the startup behavior. Because
/sessions <id> delegates to the same handler, a single call fixes both
commands.

The helper is idempotent and safe: it no-ops when the session recorded no
cwd (gateway/remote/older sessions) or when already in that directory, and
degrades to a single dim warning when the directory no longer exists.

How to Test

1. Start hermes in project A and exchange a message (session A is created).
2. Change into project B.
3. In the same CLI, run /resume <session A> (or /sessions <session A>).
4. The working directory is restored to project A — terminal, read_file,
   patch, and relative paths now resolve there.

Tests

Added regression coverage in tests/cli/test_cli_resume_command.py
(TestCliResumeRestoresCwd):

• /resume restores the recorded cwd (os.chdir + TERMINAL_CWD)
• /resume is a no-op when no cwd was recorded
• /sessions <id> restores the cwd via delegation

Results

Suite	Result
tests/cli/test_cli_resume_command.py (incl. 3 new)	15 passed
tests/cli/test_cli_init.py	41 passed
tests/cli/test_resume_display.py	40 passed
tests/cli/test_cwd_env_respect.py	9 passed
tests/cli/test_resume_quiet_stderr.py	4 passed
tests/gateway/test_resume_command.py	passed

No regressions in the resume/session/cwd paths.

Closes #38562 (interactive resume parity).

[teknium1]

Thanks for isolating the interactive-resume parity gap. The underlying bug is still present on current main: hermes_cli/cli_commands_mixin.py:669-825 restores the transcript and session state but never calls _restore_session_cwd, while startup paths do so at hermes_cli/cli_agent_setup_mixin.py:311 and :502.

Problems

• The submitted cli.py hunk no longer applies because the slash-command handlers were extracted by 094aa85c3 into hermes_cli/cli_commands_mixin.py; GitHub currently reports this PR as conflicting.

Suggested changes

• Transplant the helper call after hermes_cli/cli_commands_mixin.py:825. /sessions <id> already delegates to this handler at :857, so that single placement covers both command forms.
• Preserve the focused regression tests for recorded and absent cwd metadata.

Automated hermes-sweeper review.

[teknium1]

The fix direction is correct, but this handler has moved on current main. Transplant this call after the display branches in hermes_cli/cli_commands_mixin.py:825; /sessions <id> still delegates to that handler.

[OutThisLife]

Rebased onto current main in #67287 (your commits preserved via Co-authored-by). As teknium's review flagged, the slash-command handlers were extracted from cli.py into hermes_cli/cli_commands_mixin.py after your base, so the cli.py hunk no longer applied — a naive cherry-pick even fuzzily misplaced the call inside new_session() (where session_meta is undefined). Transplanted _restore_session_cwd(session_meta) to the end of _handle_resume_command in its current home; /sessions <id> delegates there so both forms are covered. Your 3 regression tests carry over unchanged and pass (72 across the resume/cwd suites).

Superseding here; will close once #67287 merges. Thanks @Dusk1e — clean fix, it just had to follow the handler to its new file.

[OutThisLife]

Closing now that #67287 has merged — this is the salvage of your fix (commits preserved via Co-authored-by), transplanted into hermes_cli/cli_commands_mixin.py where the resume handlers live on current main.

Thanks @Dusk1e — clean fix; it just had to follow the handler to its new file.