feat(terminal): resolve relative path links against the pane's current directory

A relative path printed in the terminal was resolved against the session's
workingDir, which is fixed at create time and never follows a cd. In a shell
that moved into a subdirectory or a sibling repo, the link opened the wrong
file or reported "File not found".

The pane-exit watcher's batched list-panes read already carries
#{pane_current_path}. derivePaneCurrentPaths() turns those rows into one
directory per single-pane session, TmuxManager.getPaneCurrentPath() serves it
from memory, and the server applies it on the existing paneExitsUpdated tick
as SessionState.cwd, broadcasting only on a change. No new tmux call, no new
SSE event. A failed read keeps the previous answers.

Session.setCwd() uses the paneExit scoping rule: remote and Docker sessions
never get a cwd (their local pane runs the ssh or docker exec client), nor do
direct-PTY or rediscovered sessions. The value is runtime-only.

In the browser, relativeResolutionBase() picks the live cwd when known and
workingDir otherwise. It only changes the base a relative path joins: the
result is routed as before, so a target outside the workspace still goes
through the attachment routes, and file-content/file-raw are unchanged.

.changeset/pane-cwd-relative-links.md

@@ -0,0 +1,5 @@
+---
+"aicodeman": patch
+---
+
+Terminal links: a relative path printed in the terminal now resolves against the directory the session's pane is in now (tmux `#{pane_current_path}`), not only the session's start directory, so after a `cd` in a shell the link opens the file that is actually there. The value is read from the pane-exit watcher's existing batched pane read (no new tmux call, no new SSE event), published as a runtime-only `cwd` field on the session state, and only changes the base a relative path joins: the workspace confinement and the attachment routing are unchanged. Remote SSH, Docker, direct-PTY and rediscovered sessions keep resolving against the working directory.