[Bug]: Grok threads do not show context-window usage in the composer

Before submitting

• I searched existing issues and did not find an active duplicate.
• I included enough detail to reproduce or investigate the problem.

Related work: the broader #5418 is closed, and #5405 is an open pre-#8358 implementation PR.

Area

apps/server

Steps to reproduce

1. Run a T3 Code build containing #8358.
2. Start a Grok thread with a model that advertises _meta.totalContextTokens over ACP.
3. Send a prompt and wait for Grok to report _meta.totalTokens in session/update or the final prompt response.
4. Inspect the context-window meter beside the composer.

Expected behavior

Grok threads should show the existing context-window meter with used tokens, maximum tokens, and fill percentage, matching Codex and other providers. The value should update when Grok reports a newer usage snapshot.

Actual behavior

The meter is absent for Grok threads.

#8358 added Grok token and cost records to the historical Usage page by parsing updates.jsonl. That is a separate pipeline. The live Grok adapter still does not emit thread.token-usage.updated, so the existing ingestion path never creates context-window.updated activity for the composer.

Impact

Minor bug or occasional failure

The failure is consistent, but it does not block a turn. Users cannot see when a long Grok thread is approaching its context limit or decide when to compact or start a new thread.

Version or commit

main after #8358 (ead4ce52a1624d9c55461f61524580978fc8b719)

Environment

Web or desktop client with the Grok provider.

Logs or stack traces

No error is shown. This is a missing provider-runtime event.

Technical notes

• ProviderRuntimeIngestion already maps thread.token-usage.updated to context-window.updated.
• ContextWindowMeter already renders that activity. No new UI component is needed.
• Grok exposes context fill through ACP _meta.totalTokens and model capacity through availableModels[]._meta.totalContextTokens. A standard ACP usage_update should also be accepted when available.
• #5405 demonstrates the intended behavior and contains focused tests, but it predates #8358 and should be rebased or manually ported rather than merged unchanged.
• Keep the change on top of #8358's current AcpRuntimeModel, GrokAcpSupport, and GrokAdapter structure.

Acceptance criteria

• A usage-bearing Grok notification or completed prompt emits a positive thread.token-usage.updated snapshot.
• The snapshot includes the active model's context-window maximum when Grok advertises it.
• The existing composer meter appears and updates for Grok threads.
• Interrupted turns do not overwrite the last valid context snapshot.
• Focused adapter and ingestion tests prove the public event and visible activity contract.

Workaround

There is no in-app workaround. Users can inspect Grok directly or start a new thread conservatively.

Start with GrokAdapter, GrokAcpSupport, and AcpRuntimeModel to trace usage-bearing ACP notifications and completed prompts. Compare the focused tests from #5405, then inspect ProviderRuntimeIngestion and ContextWindowMeter to verify the existing event path. Done means valid Grok snapshots include the model maximum, update the composer meter, and are not replaced by interrupted turns.