Regression: --resume=<new-uuid> no longer creates a new session at that UUID

[logar16]

Describe the bug

Summary

In prior versions of Copilot CLI, --resume=<uuid> was a flexible primitive: if the UUID matched an existing session, it resumed it; if the UUID was unknown, a brand-new session was created using that exact UUID as its session ID. This let external launchers (terminal wrappers, agency-style orchestrators, dashboard tools) pre-allocate a session ID, register it with other systems (color/tab assignment, monitoring, telemetry correlation), and then start Copilot with that ID guaranteed to be the session's identity.

In the current version (1.0.49), --resume is strictly a resume operation. Passing an unknown UUID errors out:

   Error: No session, task, or name matched '<uuid>'.

New sessions must instead be created with --name=<name>, and --name is mutually exclusive with --resume. Critically:

• The CLI now auto-generates its own session UUID; callers cannot supply one.
• --name accepts only an arbitrary string, not a UUID-shaped identifier guaranteed to be unique.
• The session's real UUID is only discoverable after launch by inspecting ~/.copilot/session-state/ or session_store.db.

Impact

Any tool that previously coordinated with Copilot by pre-generating a UUID is now broken. Concrete examples:

1. Microsoft's agency wrapper unconditionally injects cmd.arg("--resume").arg(&session_id) to assert its own UUID as the session ID for telemetry correlation. With 1.0.49, every fresh agency-launched session fails with "No session, task, or name matched ''". Adding --name to work around it triggers the mutual-exclusion "error: option '-n, --name ' cannot be used with option '--resume[=value]'".
2. Custom launcher scripts (e.g., terminal-tab launchers that reserve a tab color, register the session with a dashboard, etc.) can no longer hand a known ID to Copilot. They must either poll for the auto-generated ID after the fact or fall back to fragile name-based correlation.

Requested fix (or discussion)

Restore the ability for callers to assert the session UUID at creation time. Possible designs:

• Re-allow --resume=<unknown-uuid> to create a new session at that UUID (original behavior).
• Add an explicit flag like --session-id=<uuid> or --id=<uuid> for new sessions, distinct from --resume.
• Allow --name=<uuid> with --resume=<uuid> when they refer to the same not-yet-existing session.

The breaking change appears to have been made without a migration path for external integrators, and there's no documented way to know the real session ID before the process exits. At minimum, a documented mechanism to read the session UUID at startup (e.g., a callback, environment variable, or stdout line) would help downstream tools adapt.

Affected version

1.0.49

Steps to reproduce the behavior

copilot --resume=00000000-0000-0000-0000-000000000001
# Error: No session, task, or name matched '...'

copilot --resume=$(uuidgen) --name=test
# error: option '-n, --name <name>' cannot be used with option '--resume[=value]'

Expected behavior

If you are going to change how things work, give us a way to migrate.

In a perfect world I would suggest:

1. Allow us to specify the ID we want to use for the session
2. Give us a way to easily set the name of the session
3. Make it easy to resume an existing session

You've got some mutually exclusive overlap on these. Please come up with a good plan to support.

Additional context

No response