[Ticket]: usage query has no error/status signal for a request error-rate board

## Type

Feature

## Summary

`/admin/overview`'s "Request volume & errors" board (converse-frontends#368, the admin-area build) can only ever plot request volume: `UsageSeriesPoint` (`openapi/usage.backend.yaml`) carries no error/status signal at all — no `error_count`, no `status_code`, nothing an error-rate line could honestly be computed from. `signal_type`/`metric_name` are OTEL signal-kind fields (trace/metric/log), not outcome fields.

## Intent

The admin-overview design batch (`claude/sb-admin-dashboards`, page story `Pages/AdminOverview`) specified a requests-over-time board with an error-rate line, following the same shape a typical ops dashboard would want. The console's own honesty doctrine (ADR 0012 D8, "never fabricate a figure") means the live `/admin/overview` route cannot draw that second line — it renders request volume alone and captions the omission, citing this ticket.

## Source of truth

- converse-frontends#368 (epic: Console UI/UX revamp, phase "the admin area")
- `openapi/usage.backend.yaml`'s `UsageSeriesPoint` schema (no error/status property)
- `apps/console/src/containers/admin-overview-usage.ts`'s `requestVolumeSeries` (requests-only by design, this ticket is why)

## Current Behavior

- `UsageSeriesPoint` carries `requests`, `total_cost`, `usage_value`, token counts and latency percentiles — no field records whether a request succeeded, its HTTP/gRPC status, or any failure classification.
- There is consequently no way for the console (or any consumer of `/v1/usage/query`) to compute a real error rate from usage data today.

## Expected Behavior

- `UsageSeriesPoint` (or a sibling endpoint) carries a per-bucket error/failure count — e.g. `error_requests: i64` alongside the existing `requests` — populated from whatever outcome signal the ingest pipeline already has available (OTEL status codes on ingested spans, if that is the source), so a per-day error-rate line can be computed the same way `requests`/`total_cost` already are.
- If no outcome signal is captured anywhere in the ingest pipeline today, this ticket's resolution is to say so explicitly (a scope note here) rather than leave it open indefinitely — the frontend already degrades honestly either way (`admin-overview-usage.ts`'s `requestVolumeSeries`).

## Acceptance Criteria

- [ ] Either a new/extended field on `UsageSeriesPoint` (or documented equivalent) exposes a per-bucket error/failure count, OR this ticket is resolved as "no outcome signal exists to expose" with that decision recorded here.
- [ ] If a field is added: schema updated (`usage.backend.yaml`), a service-layer test asserting the count reflects real ingested failures, and `cargo test` green.
- [ ] Verification evidence is provided.

## Out of Scope

- Any change to `requests`/`total_cost`/other existing `UsageSeriesPoint` fields.
- The frontend wiring for the resulting error-rate line — a follow-up console ticket once this lands.

## Technical Context

- `openapi/usage.backend.yaml` (`UsageSeriesPoint`, `UsageQueryResponse`).
- `apps/console/src/containers/admin-overview-usage.ts` (`requestVolumeSeries`) and `apps/console/src/containers/use-admin-overview-screen.ts` (dashboard 6 wiring, the caption citing this ticket).

## Risks

- If genuinely out of scope for the ingest pipeline (e.g. no status signal is ever captured from the proxied requests), close as won't-fix with that decision recorded — the frontend already has an honest fallback either way.

## Test Plan

- Schema review + service-layer test for the new field, if added.
- `cargo test` in the affected crate(s).

## Verification evidence

Filed from the admin-area build (converse-frontends#368): traced through `openapi/usage.backend.yaml`'s `UsageSeriesPoint` schema and confirmed no error/status/outcome field exists on it, so `/admin/overview`'s "Request volume & errors" board can only honestly plot volume today.

## Human accountable owner

@stephane-segning

## AI Usage Declaration

- Understanding code
- Drafting the ticket

## Human verification completed

- [x] I understood the intent
- [x] I checked the source of truth
- [x] I reviewed all AI-generated text/code
- [ ] I am the accountable owner and accept responsibility for this ticket. (pending @stephane-segning's own sign-off — filed by an AI agent per converse-frontends#368's admin-area build, not yet human-reviewed)

Start with openapi/usage.backend.yaml, focusing on UsageSeriesPoint and UsageQueryResponse, then trace the usage query service and ingest pipeline for an existing outcome signal. If a field can be added, update the schema, add the service-layer failure-count test, and run cargo test; otherwise record that no outcome signal exists. Done means verification evidence and one acceptance path are documented.

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