Feature: surface ACP prompt-result usage (token counts) in the existing token usage UI

## Context

BitFun's ACP client currently only surfaces **context-window usage** (`ContextUsageUpdated` / `AcpSessionContextUsage`) for attached agents. However, the ACP wire already carries **per-session cumulative token usage** on `session/prompt` responses, per the ACP spec's `SessionUsage` type:

```json
{
"jsonrpc": "2.0",
"id": 3,
"result": {
"stopReason": "end_turn",
"usage": { "inputTokens": 19683, "outputTokens": 3, "totalTokens": 19686 }
}
}
```

(captured from a real `session/prompt` round against the `omp acp` agent, i.e. oh-my-pi's native ACP server)

## Proposal

Consume the `usage` field from prompt results in the ACP client layer (`src/crates/interfaces/acp/src/client/stream.rs` / `manager.rs`) and feed it into the existing web-ui token usage pipeline (`src/web-ui/src/flow_chat/types/flow-chat.ts` → `TokenUsage`, `src/web-ui/src/flow_chat/utils/tokenUsageDisplay.ts`), so ACP-attached agents show per-session token usage the same way internal-harness agents already do.

## Notes

- Today only some agents emit the field (omp does; kimi-code's `kimi acp` and zed's `claude-code-acp` / `codex-acp` adapters currently don't). Displaying it where available costs nothing and gives adapter authors an incentive to fill it in.
- This is about *token counts*, not plan quota — I'll file the quota display idea separately.

Happy to test a PR branch against my local fleet (kimi / omp / claude / codex adapters) if useful.

Trace ACP prompt responses in src/crates/interfaces/acp/src/client/stream.rs and manager.rs, then follow the existing token pipeline through src/web-ui/src/flow_chat/types/flow-chat.ts and src/web-ui/src/flow_chat/utils/tokenUsageDisplay.ts. Confirm how ContextUsageUpdated and TokenUsage flow today. Done means ACP session/prompt usage is displayed in the existing token usage UI when the response provides it, without breaking agents that omit usage.

Written by the indexing model from the issue text.