Desktop context-usage counter stays stale during active multi-tool turns

**Describe the bug**

During an active multi-tool turn in Goose Desktop, token usage displayed on individual model responses increases after each provider invocation, but the session context counter beside the chat input does not update until the entire prompt finishes.

For example, a completed model invocation can report `17k tok` while the input-area context indicator still shows `0 / 128k`. If the model continues through additional tool calls, the input counter remains stale throughout that work and then jumps to the final total only when the outer prompt completes.

The two displays are therefore describing the same growing session at different points in time:

- Message-level usage updates after each model invocation.
- The input-area session counter updates only at the end of the complete prompt, after all tool iterations finish.

This is most noticeable with local models performing long tool-call chains, where a single user prompt may contain many model → tool → model iterations.

---

**To Reproduce**

1. Open Goose Desktop using a provider that reports token usage. I reproduced this with a custom OpenAI-compatible vMLX provider.
2. Enable the Developer extension so the `shell` tool is available.
3. Start a new session.
4. Submit a prompt that requires several sequential tool calls, for example:

```text
Use the shell several times in sequence. First run `printf one`, then
`printf two`, then `printf three`. Wait for each result before issuing
the next command. Finally summarize the three outputs.
```

5. While Goose is still executing the turn, compare:

- The token usage displayed on each completed model invocation.
- The context counter beside the chat input.

6. Observe that the model-invocation usage increases while the input-area counter remains at its earlier value—initially `0` in a new session.
7. After the complete prompt finishes, observe that the input-area counter finally jumps to the latest total.

The discrepancy is easiest to see during a longer tool chain, before the final answer is produced.

---

**Expected behavior**

Whenever Goose receives and records updated context usage after a model/tool iteration, Desktop’s session context indicator should receive a corresponding update while the prompt is still active.

The counter does not need to update for every streamed output token. Updating after each completed provider invocation would be sufficient and would keep it consistent with the usage already visible on individual messages.

The final end-of-prompt update should remain as the authoritative final snapshot.

---

**Screenshots**

A screenshot from the reproduction shows a completed invocation reporting approximately `6k tok` while the context indicator beside the chat input still displays `0 / 128k`.

---

**Please provide the following information**

- **OS & Arch:** macOS 26.6.2 arm64
- **Interface:** Desktop
- **Version:** v1.48.0
- **Extensions enabled:** Developer
- **Provider & Model:** Custom OpenAI-compatible provider using vMLX – `dealignai/DeepSeek-V4-Flash-0731-JANG-CRACK` (`local-model` alias)

---

**Additional context**

This appears to be an ACP notification-timing discrepancy rather than a failure to collect provider usage.

During each model/tool iteration, Goose records updated usage and emits the per-message usage information that Desktop displays next to the completed invocation. However, the session-wide ACP `usage_update` used by the input-area context counter is not sent until the complete `session/prompt` operation finishes.

As a result:

- The message-level usage display is current.
- The session context indicator is stale.
- Long-running tool chains can leave the visible session counter inaccurate for the entire duration of the turn.

This is related to, but distinct from:

- #8132, which concerns Goose consuming final usage from an external ACP provider.
- #10429, which concerns Desktop dropping the context-window `size` reported by ACP providers.
- #11072, which concerns when backend automatic compaction is evaluated during tool loops.

This report concerns the timing of the cumulative `used` value when Goose itself is acting as the ACP agent for Desktop. It does not concern context-window-size resolution or the backend’s compaction decision points.

A useful verification case would be a prompt that causes two model invocations separated by a tool call. The ACP client should observe cumulative session usage after the first invocation, again after the second invocation, and finally at prompt completion.