feat: session-based token tracking dashboard and Copilot session title integration

[rbinar]

What was done?

Status Bar & Webview Panel

• Added DeepSeek icon (hubot) to the status bar
• Clicking it opens a webview panel showing balance, token usage, and cost

Session-Based Token Tracking

• Each Copilot Chat conversation is grouped as a single session
• Multiple messages within the same chat (e.g. "hey", "how are you") are aggregated into one group
• Grouping uses Copilot Chat's own session ID from chat.ChatSessionStore.index
• Clicking a session card expands a per-request detail table (model, in/out tokens, cost)

Copilot Session Title Integration

• Reads Copilot Chat session titles from the state.vscdb SQLite database
• Falls back to <userRequest> content when Copilot hasn't generated a title yet ("New Chat")
• Session ID-based grouping is stable; titles can update later without breaking groups

Daily History

• Token usage persisted via VS Code globalState
• Auto-resets at midnight, archiving the previous day into history
• history link in the panel shows past days

Other

• maxInputTokens increased from 655,360 → 1,000,000
• Added deepseek-copilot.contextSize configuration property
• reset button in the panel to clear all data
• Balance, API Keys, Usage, Status quick links
• Estimated cost display (USD)

Why?

1. Track token usage — DeepSeek API is pay-as-you-go; seeing costs is essential
2. Session-based grouping — Know which conversation consumed how many tokens at a glance
3. Copilot session titles — Groups match the conversation names in Copilot Chat's own sessions panel, avoiding confusion
4. Usage history — Understand daily/monthly usage patterns over time

deepseek-panel.mov

[Vizards]

Hi @rbinar, thank you for putting this together. There is a lot of thoughtful work here, especially around making usage/cost visible and improving the panel UX.

After digging into the session-tracking approach, I don’t think we should continue with this PR in its current direction. The main concern is architectural rather than implementation effort: chat.ChatSessionStore.index / state.vscdb is VS Code internal storage, not a stable extension API contract. Its storage scope, schema, and update timing can change, and picking the most recent lastMessageDate cannot reliably identify the chat session for a specific provider request, especially across multiple windows, workspaces, or concurrent chats.

For this feature to be robust, VS Code needs to expose a stable chat/session identity to LanguageModelChatProvider.provideLanguageModelChatResponse() directly. There is already an upstream feature request for exactly this: microsoft/vscode#305853

Because session grouping would be misleading if it ever attributes usage to the wrong conversation, I’d rather not build on top of private storage heuristics. I’m going to close this PR for now, but I really appreciate the exploration here. If VS Code exposes a stable session id in the provider API later, I’d be happy to revisit this feature on that foundation.

I hope this doesn’t come across as dismissing the work. The UX direction is useful; I just don’t want us to ship a feature whose correctness depends on VS Code internals we don’t control.

[rbinar]

Reworked this in #163 per the architectural feedback — all VS Code internal storage access (state.vscdb, ChatSessionStore.index, sqlite3, lastMessageDate) is removed.

The panel now aggregates usage purely from the provider's own request stream: daily totals, per-model breakdown, and chronological per-request list. No more session-to-chat mapping heuristics that could misattribute across windows/workspaces.

Conversation-level grouping is intentionally deferred until VS Code exposes a stable session id (tracking microsoft/vscode#305853) — left a clean seam for it.

See #163 for the full diff and reasoning.