Resolve operator names via on-chain data, not a hard-coded map

## Description

Resolve operator/contract display names by reading `name`/`description` from the operator contract via `eth_call`, with the raw address as fallback. Restrict the hard-coded address entries in `apps/explorer/src/constants/known-addresses.ts` to known customer/payer accounts.

## Why

- The current map (`known-addresses.ts`) needs a PR per operator/payer and can't be verified against the address. It stays useful for payer accounts, but operator accounts are expected to be smart contracts — info like `name` should be readable on-chain directly.
- It doesn't scale to multi-operator services. FCSS deploys one operator contract per client deal — unbounded addresses — so a static map can never keep up. pay.filecoin.cloud already shows FCSS rails but can't label them.
- Once names live on-chain (starting with https://github.com/FilOzone/filecoin-services/issues/535 & FRC following up), the dashboard resolves them with zero per-operator config and stays correct as new operators deploy.

## Acceptance criteria

1. For operator addresses, attempt to read `name` (and `description`) via `eth_call`; if present and non-empty, display it; else fall back to the address.
2. Remove operator entries from `known-addresses.ts`.
3. Payer accounts unchanged — they're anonymous wallets, keep showing raw addresses.

Start with apps/explorer/src/constants/known-addresses.ts and trace where its operator and payer entries are used to assemble display names. Identify the existing operator lookup and eth_call entry point, then verify the name and description fallback behavior. Done means operator entries are removed, payer labels are unchanged, and non-empty on-chain values display with the raw address as fallback.

Written by the indexing model from the issue text.