Surface session working directory / context on `SessionMetadata` so persisted sessions can be resumed by id

Start with SessionMetadata and the list_sessions and get_session_metadata entry points, then compare them with ResumeSessionConfig, SessionListFilter, and SessionRpcMetadata::snapshot. Trace where dormant-session metadata is assembled and how the existing context fields are represented. Done means optional, additive working-directory and context fields are returned by both metadata calls and support resuming a persisted session by id.

Summary

Client::list_sessions and Client::get_session_metadata return SessionMetadata, which today carries only:

pub struct SessionMetadata {
    pub session_id: SessionId,
    pub start_time: String,
    pub modified_time: String,
    pub summary: Option<String>,
    pub is_remote: bool,
}

There is no way to recover a persisted session's working directory (or its repository / git-root / branch context) from these calls. This makes it impossible to faithfully resume a session by id after the consuming process has restarted.

Why this is a gap

ResumeSessionConfig asks the caller to supply the working directory:

pub struct ResumeSessionConfig {
    pub session_id: SessionId,
    pub working_directory: Option<PathBuf>,
    // ...
}

A consumer that persists only a session_id (the documented, stable handle for resume) and later wants to resume it has a chicken-and-egg problem: it needs the session's original working directory to resume correctly, but the SDK provides no way to look that up from the id. After a restart, the in-memory mapping from id to working directory is gone, and list_sessions / get_session_metadata don't return it.

The data already appears to exist server-side

Two public-surface signals suggest the working directory / context is already tracked per session and just isn't surfaced on SessionMetadata:

1. SessionListFilter already lets callers filter list_sessions by cwd, git_root, repository, and branch:

   pub struct SessionListFilter {
       pub cwd: Option<String>,
       pub git_root: Option<String>,
       pub repository: Option<String>,
       pub branch: Option<String>,
   }
   

   i.e. the server can match on these fields, but the returned metadata omits them — an asymmetry between what you can filter on and what you get back.

2. The experimental session.metadata.snapshot RPC (SessionRpcMetadata::snapshot) already returns working_directory plus a workspace summary (cwd / git_root / repository / branch / name), selected_model, and more — but only for an active (already-resumed) session, so it can't be used to discover where a dormant session should be resumed.

Proposed change

Surface the session's working directory and context on the dormant-session metadata path, so it can be recovered by id without first resuming:

• Add the working directory (and ideally the cwd / git_root / repository / branch context, and the user-provided name) to SessionMetadata, returned by both list_sessions and get_session_metadata.
• All new fields optional / additive, so this is backward compatible for existing consumers.

This lets a consumer that persisted a session_id look up the session's working directory and resume it faithfully across restarts, and render accurate session lists (working directory, title) without having to resume each session first.

Alternatives considered

• Persisting an id-to-working-directory map in the consumer. Works, but duplicates state the runtime already owns and can drift from the on-disk source of truth — hence this request to make the SDK the single source of truth.