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: <uuid> trailer to the commit message. That trailer value is the cloud session id (mc_session_id), but copilot --resume <uuid> 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 <that-id> 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:

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: <uuid> trailer value.
3. Run copilot --resume <that-uuid>.
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 <id> 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:

grep -rl "mc_session_id: <TRAILER_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.

まず、copilot --resume の検索処理と、Copilot-Session commit trailer を書き込むコードから始めます。session-store.db、ローカルの session-state/*/workspace.yaml、および id/mc_session_id フィールドを調べ、2つの識別子がどのように関係しているかを追跡します。完了の条件は、コミットからコピーした id で対応するローカルセッションを再開できるか、再開可能な id を明確に確認でき、報告された再現結果が検証されていることです。