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

Inizia leggendo open-sessions-state.json e segui il percorso con cui i dati del session store arrivano all'elenco delle schede, al selettore /resume e al selettore /session. Verifica come la directory di lavoro o il repository viene rappresentato nel session store. Il lavoro è completato quando le sessioni mantengono questa associazione e i selettori usano per impostazione predefinita il repository corrente, continuando comunque a offrire una vista di tutte le sessioni.

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