[Feature Request]: Support JWT Auth Token Revocation

### Implementation ideas

## Summary

There is currently no way to invalidate a previously issued JWT auth token for a DA node. Once a token is created via `celestia auth `, it remains valid indefinitely with no mechanism to revoke it. Node operators should be able to revoke tokens that are no longer needed, potentially compromised, or were issued in error.

## Motivation

This came up while onboarding an integration, who had questions about the auth model. The current behavior — where issued JWTs are permanently valid with no revocation path — is a security concern and goes against standard auth best practices. Telling integrators "once you create a JWT it's valid forever, good luck" is not a great story, and it's not something that can be papered over with documentation.

Concrete scenarios where revocation matters:

- **Credential rotation**: An operator wants to cycle tokens periodically as a security hygiene practice
- **Compromised tokens**: A token is accidentally leaked (e.g. committed to a repo, shared in logs) and needs to be killed immediately
- **Access downgrade**: An `admin`-level token was issued but the consumer should have only had `read` access — there's no way to pull it back
- **Team offboarding**: A team member or integration partner no longer needs access to the node's RPC

## Current Behavior

1. Operator generates a token: `celestia light auth admin --p2p.network `
2. Token is signed with the node's key and returned
3. Token is valid forever (or until the signing key itself is changed, which is a nuclear option that invalidates *all* tokens)

There is no `revoke`, `invalidate`, or `delete` command. There is no token denylist. The only workaround is to regenerate the node's signing key entirely, which breaks all existing tokens — not granular and very disruptive.

## Proposed Behavior

Add the ability to revoke individual JWT tokens. Possible approaches (not mutually exclusive):

1. **Token denylist/blocklist**: Maintain a persistent list of revoked token IDs (`jti` claims) in the node store. The auth middleware checks incoming tokens against this list before granting access. A new CLI command like `celestia auth revoke ` would add entries.

2. **Token listing + revocation**: Add `celestia auth list` to show active/issued tokens (or at least their `jti` and permission level), and `celestia auth revoke ` to invalidate a specific one.

3. **Short-lived tokens + refresh**: Issue tokens with shorter expiration windows and provide a refresh mechanism. This limits the blast radius of a leaked token without requiring explicit revocation. (Note: v0.20.4 added nonce and expiration time via #3967, which is a step in this direction. `celestia light auth admin --p2p.network mocha --ttl 100s`)

4. **Signing key rotation per-permission-level**: Allow rotating the signing key for a specific permission level (e.g. just `admin`) without invalidating `read`/`write` tokens.

## Additional Context

- The v0.20.4 release included a fix for JWT token nonce and expiration time (#3967), which is related but doesn't solve the revocation problem for already-issued long-lived tokens.
- This is a real pain point for integration partners trying to build on Celestia's DA layer. A clear token lifecycle (create → use → revoke) is table stakes for any auth system they'd be evaluating.

## Labels

`enhancement`, `auth`