Add BYOC gateway metrics for routing, health, and spend observability

@rickstaa is already working on this.

Since Apr 22, 2026.

Description:

```markdown
**Is your feature request related to a problem? Please describe.**

Yes. The BYOC gateway path works, but the current Prometheus metrics do not expose enough context for day to day gateway operations.

Right now, operators have to stitch together several partial signals:

- Traefik request counts for public gateway traffic
- Livepeer gateway metrics for basic health and payment state
- custom TicketBroker event scanning for settled spend
- external FX data for readable USD values
- app analytics for token totals and cost per token estimates

That makes the dashboard fragile. It is hard to answer basic operational questions from Livepeer metrics alone:

- Which orchestrator handled this BYOC request?
- Which capability and model were selected?
- Did the gateway retry or fail over to another orchestrator?
- Did the selected orchestrator fail, or did the runner fail behind it?
- Which orchestrators are currently advertising `openai-chat-completions`?
- How much capacity is available for a capability right now?
- What is p50, p95, and p99 latency by capability, model, and orchestrator?
- How much did we actually spend for this model over this window?
- What was the realized spend per request or per 1M tokens?
- Are winning tickets being redeemed, and how long does redemption take?

**Describe the solution you'd like**

Please expand the existing Livepeer Prometheus `/metrics` surface used with `-monitor` for BYOC gateway and orchestrator traffic. I am not asking for a new diagnostics API or a separate dashboard format.

The most useful metric areas would be:

| Area | Example metric shape | Useful labels | Why it matters |
| --- | --- | --- | --- |
| BYOC request volume | `livepeer_byoc_requests_total` | `capability`, `model`, `route`, `status_class`, `orchestrator` | Shows request volume and success rate without relying on Traefik as a proxy for gateway behavior. |
| BYOC failures | `livepeer_byoc_request_failures_total` | `capability`, `model`, `stage`, `reason` | Separates gateway routing failures from orchestrator, runner, timeout, and payment failures. |
| Orchestrator selection | `livepeer_byoc_orchestrator_selected_total` | `capability`, `model`, `orchestrator`, `selection_result` | Shows which orchestrators are receiving work and whether selection is succeeding. |
| Retry and failover | `livepeer_byoc_orchestrator_retries_total` | `capability`, `model`, `from_orchestrator`, `to_orchestrator`, `reason` | Makes routing instability visible before it appears as user-facing errors. |
| Capability registration | `livepeer_byoc_capability_registered` | `capability`, `model`, `orchestrator` | Shows which orchestrators are currently eligible for a BYOC capability. |
| Capability capacity | `livepeer_byoc_capability_capacity` | `capability`, `model`, `orchestrator` | Shows advertised serving capacity without parsing logs or capability responses. |
| Active and queued jobs | `livepeer_byoc_jobs_active`, `livepeer_byoc_jobs_queued` | `capability`, `model`, `orchestrator` | Shows whether latency comes from queueing, runner execution, or upstream request time. |
| Job latency | `livepeer_byoc_job_duration_seconds` | `capability`, `model`, `orchestrator`, `status` | Supports p50, p95, and p99 latency dashboards. |
| Runner health | `livepeer_byoc_runner_up` | `capability`, `model`, `orchestrator`, `runner` | Shows when the orchestrator is healthy but the runner behind it is unavailable. |
| Token accounting | `livepeer_byoc_prompt_tokens_total`, `livepeer_byoc_completion_tokens_total`, `livepeer_byoc_tokens_total` | `capability`, `model`, `orchestrator` | Lets operators calculate cost per token without joining against app analytics. |
| Tickets sent | `livepeer_byoc_ticket_value_sent_wei_total`, `livepeer_byoc_tickets_sent_total` | `capability`, `model`, `orchestrator` | Connects BYOC work to payment tickets at the same label level as request metrics. |
| Winning tickets | `livepeer_byoc_winning_ticket_value_wei_total`, `livepeer_byoc_winning_tickets_total` | `capability`, `model`, `orchestrator` | Shows realized settlement without a custom chain event scanner. |
| Redemption state | `livepeer_byoc_ticket_redemptions_total`, `livepeer_byoc_ticket_redemption_errors_total`, `livepeer_byoc_ticket_redemption_lag_seconds` | `orchestrator`, `status` | Shows whether winning tickets are being redeemed and whether redemption is delayed. |
| Spend per unit | `livepeer_byoc_spend_per_request_wei`, `livepeer_byoc_spend_per_token_wei` | `capability`, `model`, `orchestrator` | Gives operators direct cost panels without fragile PromQL joins. |

The labels should be useful but bounded. Good labels would include `capability`, `model`, `route`, `status`, `status_class`, `stage`, `reason`, `orchestrator`, `runner`, and `gateway`.

Labels to avoid by default:

- raw request IDs
- prompts or prompt hashes
- user IDs
- client IPs
- full error strings
- bearer tokens, wallet keys, or any credential material

For `reason`, a controlled set of values would be enough, for example `timeout`, `runner_error`, `payment_error`, `allowlist_rejected`, `no_capacity`, `capability_missing`, or `orchestrator_unreachable`.

**Describe alternatives you've considered**

We have worked around this by joining Livepeer metrics with Traefik, custom TicketBroker event scans, FX data, and app analytics. That works for a local dashboard, but it is not a clean operator experience and it is easy to get wrong.

We also considered asking for JSON diagnostic endpoints, but Prometheus metrics fit the existing Livepeer monitoring model better and should be easier for operators to consume.

**Additional context**

The desired outcome is that a gateway operator can build dashboards and alerts from Livepeer metrics alone for:

- BYOC request volume, success rate, and failure reasons
- orchestrator selection and routing distribution
- orchestrator health, runner health, active jobs, queue depth, and capacity
- latency by capability, model, and orchestrator
- tickets sent, winning tickets, redeemed value, and redemption errors
- actual spend by model and orchestrator
- spend per request and spend per 1M tokens
- gateway deposit and reserve state

This would make BYOC gateway operations much easier to reason about, especially when multiple orchestrators and external runners are involved.
```