/cd skips relocating a session when target path resolves to the same physical cwd as a symlinked path used to bypass the resume directory check

Summary

/cd <path> is documented to "move this session to a new working directory" and relocate it "to the new directory's project storage, so --resume and --continue find it from there." When the current working directory was reached via a symlink whose physical target equals the /cd argument, the command reports "already in <path>" and declines to relocate — even though the session's recorded/original directory is still the pre-symlink path, not the physical one. It isn't failing silently; the reported message is just wrong, because it's comparing against the resolved physical cwd instead of the session's recorded directory.

Repro

1. Have a session recorded with original directory /some/original/path (e.g. copied from another machine — its .jsonl transcript still lists that path).
2. On the new machine, mkdir -p a stand-in and symlink it to the real project directory:

``
sudo mkdir -p /some/original/path/.. # parent scaffolding as needed
sudo ln -s /real/project/dir /some/original/path
``

1. cd /some/original/path && claude --resume <session-id> — this succeeds because the shell's logical cwd matches the recorded directory.
2. Inside the session, run /cd /real/project/dir (the physical target the symlink points to).
3. Expected: the session relocates — recorded directory and project storage now point at /real/project/dir.
4. Actual: Claude Code reports "already in /real/project/dir" and does not relocate, because it compares the target against the resolved/physical cwd rather than the session's recorded directory.

Workaround

Bounce through an unrelated directory first to force a real comparison:

/cd /tmp
/cd /real/project/dir

This works because /tmp differs from both the recorded directory and the physical cwd, so the second hop is no longer seen as a match and the relocation actually runs.

Context

This is the exact situation anyone hits doing cross-machine session handoff (copying a session's transcript to a different box to resume it there) — a workflow the docs explicitly anticipate (/cd's "finds the moved session from any other directory" note). Without the double-hop workaround, /cd reports a misleading "already in" message and there's no direct way to get it to adopt a new canonical directory once you've gotten in via a directory-matching trick.

Possible fix

/cd's equality check (the one that decides whether to report "already in <path>") should compare the target against the session's recorded directory, not the physical/resolved current working directory.

Related

This looks like the same root-cause family (symlink vs. physical-path resolution inconsistency) as #73335, #72049, and #74043 — each hits a different subsystem (CLAUDE.md loading, auto-memory, session index) but all stem from the harness resolving cwd through symlinks in some code paths and not others. Flagging in case a fix should address the pattern generally rather than per-subsystem.

Environment: Claude Code CLI, Linux (Debian), cross-machine session resume (laptop → Hetzner Cloud box)