Composer token-usage tooltip caps the denominator at 128,000 regardless of the model's actual context window

### Before filing

- [x] I searched open and closed issues for duplicates.
- [x] I reproduced this on the latest release.
- [x] This is one bug, not several bundled together.

### Closest existing issue

#106 (about defaulting Codex sessions to the 272K pricing boundary) is adjacent — it's about which window Codex *sessions* should use, while this report is about the composer token meter displaying a wrong window for models whose real context size differs from 128K.

### What's broken

The token-usage tooltip on the composer (hover over the progress circle next to the send/stop buttons) always shows a denominator of **128,000 tokens**, even when the session's model has a much larger context window. The numerator can also exceed the denominator many times over — in my session it reads **`5,145,485 / 128,000 tokens`** — so the meter conveys no usable information about how full the context actually is.

### Steps to reproduce

1. Launch Berd (0.6.2)
2. In the local Claude Code setup, enable the 1M-token context window (the model appears in Berd's picker as `Claude Fable 5[1m]` / model_id `claude-fable-5[1m]` on the `claude-acp` harness). Same applies to a Codex model configured for a 400K window.
3. Create a session with that model and use it for a while (long conversation / many turns)
4. Hover the token-usage indicator at the bottom-right of the composer

### What you expected to happen

The denominator should reflect the model's actual context window (1,000,000 for the `[1m]` Fable model, 400K for the configured Codex model), and the numerator should stay ≤ the denominator if it represents context occupancy. If the numerator is instead cumulative session usage, the two numbers shouldn't be presented as a single `used / limit` fraction.

Also: if there is a way for users to set/override the context window Berd assumes per model, I couldn't find one — that would be a fine resolution too.

### What actually happened

Tooltip shows `5,145,485 / 128,000 tokens`. The numerator is ~40× the denominator and the session keeps working fine (the harness itself has the 1M window), so the 128,000 looks like a hardcoded fallback rather than the real limit.

Possibly relevant: `berdctl info models --json` returns only `model_id` and `name` per model — no context-length metadata — so the app plausibly has no way to know the real window for harness-defined models like `claude-fable-5[1m]` and falls back to a 128K default.

### How often does it happen?

Every time — reliably reproducible

### Berd version

0.6.2

### Operating system

macOS (Apple Silicon)

### Model and provider

Claude Fable 5[1m] via the claude-acp (Claude Code) harness / Anthropic; also observed with a Codex model configured for a 400K window

### Relevant log output

```
no relevant log output — grepped ~/Library/Logs/xyz.block.berd/berd.log for token/context/limit lines around the time of observation; nothing matched
```

### Screenshots, recordings, or other context

Screenshot of the tooltip will be attached in a comment below (filed via `gh` CLI, which can't upload attachments).

Start at the composer token-usage tooltip and trace how its model limit and numerator are obtained; then inspect the output of `berdctl info models --json` and the `claude-acp` model configuration for available context metadata. Verify the 1M Claude Fable and 400K Codex cases, and ensure the tooltip either shows the actual context limit with occupancy or clearly distinguishes cumulative usage from a limit.

Written by the indexing model from the issue text.