filter/scope session tabs & resume list by repository/solution

Bắt đầu bằng cách đọc open-sessions-state.json và lần theo cách dữ liệu của session store đến danh sách tab, bộ chọn /resume và bộ chọn /session. Xác nhận thư mục làm việc hoặc repository được biểu diễn như thế nào trong session store. Được xem là hoàn thành khi các session duy trì mối liên kết đó và các bộ chọn mặc định sử dụng repository hiện tại, đồng thời vẫn cung cấp chế độ xem tất cả các session.

Describe the feature or problem you'd like to solve

Currently, the session tab list and  /resume  picker show all sessions across every repo/solution I've worked in, sorted purely by recency. There's no per-repository scoping —  open-sessions-state.json  only stores  openedAt / working / refreshedAt , no  cwd / repository  field, so the UI has nothing to filter on even if it wanted to. This becomes a real problem when working across multiple unrelated solutions on the same machine (e.g. a Blazor support app vs. an NLQuery/report agent vs. WCF services): sessions from completely different codebases end up mixed together in the tab list, making it hard to find the session relevant to the solution I currently have open.

Proposed solution

persist the working directory/repository per session (the data already exists in the session store itself, just not surfaced in  open-sessions-state.json ), and let the tab list /  /resume  /  /session  picker filter or group by "sessions for this repo" by default, with an option to show all.

Example prompts or workflows

1. "Resume an old session for this project" — I open solution X, type  /resume , and only see sessions that were ever started in X, instead of scrolling through dozens of sessions from unrelated projects to find the right one.
2. Context-switching between multiple codebases on one machine — I work on a Blazor support app, a WCF service layer, and an NLQuery reporting agent in turn. With per-repo filtering, each tab list stays scoped to that project, so I never accidentally continue a session that was actually about a completely different codebase.
3. "Where did I leave off on this project?" — After being away from a specific solution for a few days, I open that folder and want to instantly see only the sessions relevant to it, sorted by recency — not my entire cross-project history mixed together.
4. Cleaning up/archiving per project — With repo scoping, I can more easily bulk-clean old sessions from a finished project without risking accidentally losing active sessions from a different project in the process.
5. Onboarding/handover — If I want to show someone "all Copilot sessions done on this project," a repo-filtered list is immediately usable as an overview, instead of first manually filtering out noise from other projects.

Additional context

No response