/resume broken for all non-git sessions

[Fabi0San]

Describe the bug

Summary

/resume is effectively unusable for any session that was created while the
working directory was NOT a git repository. Such sessions store
repository = '/', and the resume picker's git gate then makes them
impossible to select — a true catch-22. Separately, cross-machine sessions
can't be recovered, and --connect silently starts an empty session instead
of surfacing the problem.

Environment

• GitHub Copilot CLI: 1.0.69-0
• OS: Windows 11
• Repro also relevant to earlier 1.0.6x per Resume fails if repository name does not match #3694

The catch-22 (core bug)

A session created outside a git repo has repository = '/' in its metadata
(upstream cause: #2655 — cwd/branch/repository not persisted). The /resume
picker enforces two mutually exclusive requirements:

1. Must be INSIDE a git repo, else:
   Error: Not in a git repository. Please navigate to your repository directory.
2. The repo must EQUAL the session's stored repo ('/'), else:
   Error: Repository mismatch: You are in 'owner/name' but the remote session is for '/'.

No directory satisfies both. In a repo → mismatch; not in a repo → "not a git
repository." The session becomes permanently unreachable via the picker.

Reproduction

1. Run copilot in a NON-git folder, hold a conversation, exit.
2. Later, from a git repo: copilot → /resume → pick that session
   → "Repository mismatch … session is for '/'".
3. From a non-git folder: copilot → /resume → "Not in a git repository."

Workarounds attempted (all fail)

• copilot --resume=<id> → No session, task, or name matched (session isn't
  in this machine's local store when it originated elsewhere).
• Running /resume from a non-git dir → "Not in a git repository."
• copilot --connect=<id> → bypasses the git gate BUT starts a brand-new empty
  session (returns NO-HISTORY, emits a fresh --resume=<new-id>); the original
  transcript is not recovered.

Impact

• Sessions created before a folder became a git repo are lost to /resume
  (e.g., a session started, then git init run later — the very act of adding
  git makes prior sessions unmatchable).
• Cross-machine continuation is broken: a session created on machine A cannot be
  resumed on machine B at all.
• --connect failing silently (new empty session) hides the real problem.

Suggested fixes

1. Treat stored repository of '/' or empty as "unscoped" and SKIP the
   repository-match gate for those sessions — allow resume from any directory.
2. Don't hard-require a git repo to open the resume picker; git context should
   be optional metadata, not a precondition.
3. When --connect can't attach to the requested session, error explicitly
   instead of spawning a new empty session.

Related issues

#3694 (repo-name mismatch, closed), #2655 (repo/cwd not persisted),
#2446, #3671 (cloud-session resume), #3908 (empty resume dir),
#2836 (orphaned session folders), #1381 (rewind git gate), #3931.

Affected version

GitHub Copilot CLI: 1.0.69-0

Steps to reproduce the behavior

Reproduction

1. Run copilot in a NON-git folder, hold a conversation, exit.
2. Later, from a git repo: copilot → /resume → pick that session
   → "Repository mismatch … session is for '/'".
3. From a non-git folder: copilot → /resume → "Not in a git repository."

Expected behavior

Session should resume.

Additional context

Environment

• GitHub Copilot CLI: 1.0.69-0
• OS: Windows 11
• Repro also relevant to earlier 1.0.6x per Resume fails if repository name does not match #3694