feat: add context window usage to chat input

[murillocamargo]

Summary

Adds a live context tracker to the chat input so users can see context window usage directly while chatting, with a compact ring indicator and a hover card that breaks usage down into total, input, and output tokens.

This addresses #9543.

There was a previous draft attempt in #10958. This implementation reuses the general UI direction, but fixes the main stale-data problem: the context usage now updates after each chat response without requiring a conversation switch or full page refresh.

Implementation details:

• add a ContextTracker component to the chat input
• add a chat setting to enable or disable the tracker
• update token counting flow so assistant output token counts are reconciled after the final response is saved
• refresh message token data at the end of streaming so the tracker reflects the latest counts immediately
• improve tokenizer model handling for token count calculation across supported models

Demo:

• Loom: https://www.loom.com/share/fa1336cdcc99441882b9ead33d89e86d
• UI

• "Show context tracker" in Settings

Change Type

• New feature (non-breaking change which adds functionality)
• Translation update

Testing

Manual verification:

• enable the context tracker in chat settings
• send messages in an existing conversation and confirm the tracker updates after each assistant response
• verify the tracker also updates in a new conversation
• verify the hover card shows total, input, and output usage
• verify the tracker behaves correctly when max context is unavailable
• verify no refresh or conversation switch is needed to see updated context usage

Test Configuration:

• OS: WSL2
• npm Version: 11.11.1
• Branch: feat/context-tracker
• Base branch: main

Checklist

• My code adheres to this project's style guidelines
• I have performed a self-review of my own code
• I have commented in any complex areas of my code
• My changes do not introduce new warnings
• Local unit tests pass with my changes
• Any changes dependent on mine have been merged and published in downstream modules.

[danny-avila]

Thanks for the PR. However, besides the basic UI features, this is not aligned to how we want to implement this, and it's token tracking will not accurately reflect the backend token accounting.

In short, no additional tokenizer usage or awaiting database promises are necessary and there are more nuances to consider that are easily overlooked. The current approach will be off when attachments/tools/agent instructions are in play, let alone switching models, message trees, etc.

If you're curious to investigate: https://github.com/danny-avila/agents