Bug: "Worktree missing" on all project sessions (existing and new) after upgrade to desktop 2.98.0 / runtime 1.1.15

Describe the bug

Bug: "Worktree missing" on all project sessions (existing and new) after upgrade to desktop 2.98.0 / runtime 1.1.15

Summary

After the app auto-updated, every worktree-backed project session shows a
"Worktree missing — Recreate the worktree from the session menu, then retry."
screen. This affects existing sessions that previously resumed fine and
brand-new sessions created after the upgrade. Chat sessions (no worktree) are
unaffected.

The worktrees are not actually missing. This is a false negative in the new
worktree/host resolution layer introduced in this release.

Environment

• OS: Windows
• Desktop app: 2.98.0 (upgraded from 2.96.0 the same day)
• Runtime/CLI package: 1.0.83-5 (multiple runtime packages were staged in the
  same update window: 1.0.80, 1.0.83-5, 1.0.84-1)
• Data DB schema line: 1.1.14 → 1.1.15
• Install method: WinGet (GitHub.Copilot)
• Projects: mix of single-repo and multi-repo "collection" projects; local
  checkouts on both C: and E:.

Impact

• All project/worktree sessions are unusable (cannot resume or start).
• Reproduces on freshly created sessions, so it is not stale/deleted worktrees.

What I verified (the worktrees are healthy)

1. Git works. Bundled git 2.53.0.windows.4 runs fine. For a real session
   worktree, git status is clean and git rev-parse --git-dir resolves to the
   main repo's .git/worktrees/<name>. The worktree .git file and its backlink
   are intact.
2. Folders exist on disk. For a brand-new post-upgrade session, 14/16 member
   worktree folders already existed under
   C:\Users\<user>\.copilot\repos\copilot-worktrees\..., yet the session still
   reported "Worktree missing."
3. Drives/paths are fine. E: is mounted; all main repos present.
   settings.storage_location = C:\Users\<user>\.copilot\repos (correct).
4. Chat sessions on the same 1.1.15 runtime work, so the runtime itself is up;
   only worktree resolution fails.

Likely root cause (DB evidence)

Comparing the pre-update DB backups the app itself wrote:

DB backup	remote_environments table	rows	workspaces host_id
pre-update 1.1.14 (last known good)	absent	–	all local
current 1.1.15 (broken)	present	0 (empty)	all local

The 1.1.15 migration introduced a host/environment layer (remote_environments,
project_checkouts.host_id). Every existing workspace and checkout references
host_id = 'local', but there is no corresponding local host row after
migration. The new worktree-resolution path appears unable to resolve the local
host, so it reports every worktree — old and new — as missing. The migration does
not seem to backfill/register the implicit local host.

Affected version

1.1.15

Steps to reproduce the behavior

Steps to reproduce

1. Be on desktop 2.96.0 with several local project sessions (single- and
   multi-repo) that resume fine.
2. Let the app auto-update to 2.98.0 (DB migrates to 1.1.15).
3. Open any project session, or create a new one.
4. Observe the "Worktree missing" screen despite the worktree existing on disk and
   being a valid git worktree.

Expected behavior

Expected

Existing sessions resume and new sessions create/attach as before; the local
host resolves without a manual remote_environments entry.

Additional context

Notes / possible fix

• The 1.1.15 migration likely needs to backfill a local entry in the new host
  registry (or the resolver should treat host_id='local' as the implicit local
  host when no remote_environments row exists).
• Backups exist and no data was lost — rolling back to 2.96.0 + restoring
  data.db.pre-update-backup-1.1.14 restores functionality (with loss of the
  handful of sessions created after that backup).

Start by locating the 1.1.15 database migration and the worktree host-resolution path, then inspect how remote_environments and project_checkouts.host_id are read. Reproduce with a migrated database where host_id is local and remote_environments is empty. Done means existing and newly created local worktree sessions resolve successfully without manual host registration.