feat(explorer): let users manage spending limits per service

## Description

Operator approvals are token-scoped spending permissions, but the console presents them as a separate top-level table of low-level values. Once #340 introduces payer-scoped service pages, each service page should show and manage the connected payer's limits for that operator.

This issue owns ongoing authorization management. Initial limits selected while adding a service belong to #370.

## Proposed solution

Add a spending-limits section to `/console/services/[operator]`. Query `OperatorApproval` by connected payer and route operator, including active and revoked token records. Paginate with `AccountOperator.totalApprovals`.

Show the approval token, rate allowance in a human-readable period, lockup allowance, maximum lockup duration, current usage, and active or revoked status. Keep the operator fixed to the route.

Before constructing an update, read the current approval from the Payments contract. The setter accepts absolute values, so calculations must not use a potentially stale indexed allowance. Let users raise, lower, replace, or revoke limits. Warn when a proposed value is below current usage or may prevent new rails, and show old and proposed values before signing.

After confirmation, represent the indexing delay, refresh the scoped approval and account/operator queries when the receipt block is indexed, and retain recoverable rejection and failure states.

## Done criteria

- [ ] Each service page shows all token-specific current and revoked authorization records
- [ ] Unlimited values are labelled explicitly
- [ ] Users can raise, lower, replace, or revoke limits
- [ ] Updates start from fresh contract values
- [ ] Human-readable values convert to exact contract units without `number` precision loss
- [ ] Confirmation shows old and proposed values
- [ ] Values and active counters refresh after confirmation and indexing
- [ ] Tests cover finite, unlimited, stale-index, below-usage, rejection, failure, and revocation cases

## Trade-offs and risks

`rateAllowance` is an authorization ceiling, not a calendar-month budget covering every payment type. A true monthly budget may require protocol changes.

## Notes

- Blocked by the service relationship and route work in #340
- Initial authorization during Add Service belongs to #370
- Architecture reference: `docs/subgraph-architecture.md`

Start with the /console/services/[operator] route and read docs/subgraph-architecture.md, then review the service relationship and route work in #340. Trace how OperatorApproval, AccountOperator.totalApprovals, and the Payments contract are queried and updated. Done means implementing the listed finite, unlimited, stale-index, usage, rejection, failure, and revocation cases with refreshes after indexing.

Written by the indexing model from the issue text.