copilot --resume can't use the Copilot-Session commit trailer id (it's the cloud mc_session_id, not the local session id)

### Describe the bug

When Copilot CLI creates a git commit, it appends a `Copilot-Session: ` trailer to the commit message. That trailer value is the **cloud** session id (`mc_session_id`), but `copilot --resume ` only accepts the **local** session id (`id`). The two are different UUIDs for the same session, so anyone who takes the id from a commit (or from a PR that shows the trailer) and runs `copilot --resume ` fails to resume — even when the session is present locally under its local id. There is no user-facing mapping between the two ids, so the failure looks like "the session is gone" when it is not.

Concretely, a session run in `github/bosun` produced a commit whose trailer read `Copilot-Session: 127c5458-0152-411a-84f9-8f747e96ee55`. Running `copilot --resume 127c5458-0152-411a-84f9-8f747e96ee55` finds nothing: that id exists only in the cloud session store, not in the local `session-store.db` and with no local `session-state/` folder. The actual local, resumable session is `a795500d-0486-4d1c-8366-0cb5eac4e312`. The link between them is only discoverable inside the local `workspace.yaml`:

```yaml
id: a795500d-0486-4d1c-8366-0cb5eac4e312 # local id — what --resume accepts
mc_task_id: 23ce7957-5241-4990-802c-34d2a64db821 # cloud task id
mc_session_id: 127c5458-0152-411a-84f9-8f747e96ee55 # cloud id — what lands in the commit trailer
```

So the id the CLI writes into git history is not the id its own `--resume` command accepts, and nothing surfaces the correspondence to the user.

### Affected version

1.0.71-2 (also reproduced against sessions created by earlier versions on the same machine)

### Steps to reproduce the behavior

1. Start a session that has a cloud counterpart (e.g. a session with an `mc_session_id`, such as one launched from / synced with a cloud task) and let it create a git commit.
2. Inspect the commit message and copy the `Copilot-Session: ` trailer value.
3. Run `copilot --resume `.
4. Observe that the session cannot be resumed, even though the session still exists locally under a different id.

### Expected behavior

The id recorded in the `Copilot-Session` commit trailer should be resumable. Either:

- `copilot --resume ` should also match a session by its `mc_session_id` (and resolve to the corresponding local session), or
- the commit trailer should record the local `id` that `--resume` accepts, or
- when a lookup by cloud id fails, the CLI should tell the user the corresponding local id (or resume it directly).

### Additional context

Current workaround — map the trailer id back to the local, resumable id by grepping the `mc_session_id` field across local session state:

```bash
grep -rl "mc_session_id: " ~/.copilot/session-state/*/workspace.yaml
```

The folder name (and the `id:` field inside that `workspace.yaml`) is the id to pass to `copilot --resume`.

This is related to but distinct from #3671 (local changes after resuming a cloud agent session are not resumable) and #3689 (generic "can't resume session"). The core issue here is specifically that the CLI writes a non-resumable id into git commits with no surfaced mapping to the resumable local id.

Commencez par la recherche de `copilot --resume` et par le code qui écrit le commit trailer `Copilot-Session`. Examinez `session-store.db`, les fichiers locaux `session-state/*/workspace.yaml` et les champs `id`/`mc_session_id` afin de retracer la relation entre les deux identifiants. C’est terminé lorsqu’un id copié depuis un commit peut reprendre la session locale correspondante ou révéler clairement son id utilisable pour la reprise, et que la reproduction signalée a été vérifiée.

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