wallet: clarify active payment-session handling after access-key revocation

[Osraka]

Context

tempo wallet revoke correctly calls AccountKeychain revocation and removes the matching key from the local wallet store. Payment sessions, however, bind a channel to a stable authorizedSigner.

This is a distinct capability by design:

• the Tempo session specification says a channel remains open until it is explicitly closed;
• voucher validation recovers an ECDSA signer and compares it with the descriptor authorizedSigner;
• the normal non-cooperative session-close path is separate from access-key revocation.

Observed CLI behavior

In an isolated local HOME with a locally tracked active channel whose authorized_signer matches an access key:

1. revoke the key;
2. the local key disappears;
3. tempo wallet sessions list still reports the channel as active, but does not include authorized_signer, payer, or payee.

I do not think revocation should silently close a payment channel. That would create an on-chain state change and a grace period unexpectedly. The concern is operator visibility: after revoking an agent key, a user cannot tell from the revoke result which locally tracked payment sessions remain tied to that key, nor that channel closure is a separate action.

Proposed narrow direction

Could wallet-cli surface an explicitly local-only summary after a successful key revocation, scoped by (chain_id, payer, authorized_signer)? For matching non-finalized records, the output could state the number or IDs and explain that the normal remediation is tempo wallet sessions close <channel-id> (or --all with a dry run first).

This should not:

• automatically close a channel;
• claim an exhaustive on-chain search;
• change channel or keychain protocol semantics.

#63 is refactoring request-side session persistence and leaves sessions.ts unchanged. I would wait for direction on whether this belongs before implementing anything.

Questions

1. Is this distinction intended product behavior for the wallet CLI?
2. Would revocation-time local warnings be preferable to a session-details or inspect view?
3. Should work wait for refactor(request): delegate payment sessions to mppx #63 and the MPPx channel-store change?

No PR proposed yet. I can add a focused regression test and the smallest UX change once scope is confirmed.