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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.