fix: handle nested Ollama Cloud usage response and hide per-model request counts

[christian-taillon]

Summary

The Ollama Cloud /api/usage response changed shape, and the quota output showed rows that do not belong in a quota display. This PR fixes both parsing and presentation for the Ollama Cloud provider.

1. Handle the nested usage response

The parser previously expected an optional top-level payload.models array. The current response instead nests per-model data inside each quota window (limits.session.models and limits.weekly.models). Because the top-level models field is absent, the parser emitted:

Ollama Cloud: Models: expected an array

even though the Session and Weekly quota values were valid.

• Session and Weekly usage continue to come from limits.session.usage and limits.weekly.usage.
• A missing top-level payload.models is now valid and produces no warning.
• Legacy top-level payload.models remains supported when present.

2. Hide per-model request counts

The provider also emitted one row per model, for example:

[Ollama Cloud]
Weekly        ███████░   98% left
Session       ████████   99% left
glm-5.3-flash:  154 requests

Per-model request counts are usage accounting, not quota windows. They make the toast, sidebar, and command output noisy and are not comparable to the percentage-based quota rows from other providers.

This PR removes per-model request rows from all surfaces (command, toast, sidebar, compact status) and removes the associated types, metadata, diagnostics, and tests. Only the Session and Weekly quota windows are reported:

[Ollama Cloud]
Weekly        ███████░   98% left
Session       ████████   99% left

The usage API still receives and safely ignores any per-model data in the response, including the nested limits.*.models shape.

Note on reset times

Ollama Cloud does not provide reset timestamps in /api/usage (activity.period is a rolling 4-week activity report ending at request time, not a quota reset). Reset countdowns therefore remain unavailable for this provider until Ollama exposes that data, consistent with the existing Blocked: not in provider API label on the Ollama Cloud request in #38. This PR deliberately does not estimate reset times or reintroduce the unsupported settings-page cookie flow documented in providers.md.

Linked Issue

No existing issue found for the request-row removal. Scope: match the current Ollama Cloud /api/usage response shape and keep quota output limited to actual quota windows. Refs #38 for the original Ollama Cloud provider request.

OpenCode Validation

• Current production released OpenCode version tested: 1.18.11 (@opencode-ai/plugin pinned version)
• Why this version is relevant to the fix: the fix was validated against the live Ollama Cloud usage API response and exercised through the built plugin in a local OpenCode install.
• Focused Ollama Cloud tests: passed
• pnpm run typecheck: passed
• pnpm run build: passed
• Full suite: 182 files / 2173 tests passed
• git diff --check: passed

Quality Checklist

• I ran pnpm run typecheck
• I ran pnpm run build
• I ran pnpm test
• This change is focused and avoids unrelated behavior changes
• I updated or added tests when behavior changed
• I updated docs when user-facing workflow, command, or config behavior changed
• For provider changes, I followed Provider Changes: this is an existing built-in provider fix, not a new provider addition, so the models.dev/eligibility policy does not apply; the existing percent-row shape with AccountingMetadata is preserved.

Superseded head note: the branch was rebased to correct the commit author identity; content is unchanged.