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

## Summary

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

```rust
pub struct SessionMetadata {
pub session_id: SessionId,
pub start_time: String,
pub modified_time: String,
pub summary: Option,
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:

```rust
pub struct ResumeSessionConfig {
pub session_id: SessionId,
pub working_directory: Option,
// ...
}
```

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`:

```rust
pub struct SessionListFilter {
pub cwd: Option,
pub git_root: Option,
pub repository: Option,
pub branch: Option,
}
```

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.

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.