Proposal: local AI provider allowance indicator in Buzz Desktop

## Problem

Buzz users currently have to leave the app to learn whether their local AI
provider subscription is close to a rolling allowance limit.

## Proposal

Add an experimental, local-only provider allowance indicator to Buzz Desktop:

- a compact persistent sidebar ring showing the constraining allowance window
- a detail popover with every returned rolling window, resets, freshness, and
optional provider totals
- a provider capability picker under **Settings → Experiments**
- **Auto** selection plus explicit provider capabilities

The first working adapter is Codex. It reads the locally authenticated Codex
app-server over JSONL stdio and normalizes only display-safe allowance fields.
Claude and Grok appear as explicit unsupported capabilities until their vendors
provide a safe standalone personal-allowance reader.

## Provider boundary

- **Codex:** supported through the local app-server capability. The integration
preserves primary, secondary, and limit-ID-specific windows. Reads fail
closed when the installed protocol is incompatible; binary presence alone
does not prove authentication or compatibility.
- **Claude:** no standalone personal-allowance reader is currently documented.
Buzz should not reuse subscription OAuth, alter Claude settings, scrape a
terminal, or create billable work to obtain usage.
- **Grok:** consumer allowance is exposed in Grok Settings, while xAI's
Management API describes API-team billing. Buzz should not present that API
billing as SuperGrok allowance or scrape the consumer site.

This is deliberately separate from agent token/cost history and organization
API billing.

## Privacy and lifecycle

- The Codex adapter reuses the existing local Codex sign-in.
- Buzz stores only the non-secret provider preference.
- No credentials, raw responses, account identifiers, or provider error bodies
cross IPC or enter logs, analytics, crash payloads, or Nostr; only the
normalized allowance snapshot reaches the frontend.
- bounds protocol frames and total output, enforces a timeout, correlates
response IDs, and reaps the complete child process tree
- keeps stale successful data visible if a refresh fails instead of inventing
`0% left`

## Acceptance shape

- data-driven capability registry and normalized adapter contract
- correct provider-switch query isolation and persisted selection
- multiple sidebar/settings mounts coalesce through one provider-scoped query
- feature-off state launches no provider process
- unit, static, build, Tauri, and rendered UI regression coverage
- installed-canary verification against the real local provider and community

If maintainers prefer showing only supported providers, the registry-backed UI
can make that presentation change without changing the adapter boundary.

## Related and sources

- [OpenAI Codex app-server](https://learn.chatgpt.com/docs/app-server.md)
- [Claude Code status-line rate-limit fields](https://code.claude.com/docs/en/statusline)
- [Claude Code authentication policy](https://code.claude.com/docs/en/legal-and-compliance)
- [xAI Management API](https://docs.x.ai/developers/rest-api-reference/management)
- [Grok consumer usage and limits](https://docs.x.ai/grok/faq)
- [PR #2035: agent token/cost history](https://github.com/block/buzz/pull/2035)
- [PR #2653: ACP slash-command autocomplete](https://github.com/block/buzz/pull/2653)