rpc: centralize block-selector validation without changing endpoint errors

## Problem

RPC handlers repeat two related block-selector policies:

- `debug_accountAt` and the `eth_getLogs` block-hash path resolve a header number, read the canonical hash, and compare it locally;
- `erigon_getLogs` and `erigon_getLatestLogs` resolve any known header hash to a number and then scan canonical logs at that height, so a side-chain hash can return another block's logs;
- committed-state endpoints reject `pending` through `rejectPendingState`, while tracing uses `rejectPending` and `rejectPendingNumber` with a different client-visible error.

The checks are simple, but copies have already drifted in canonicality, pending handling, and error mapping. A direct replacement with one generic error would also be wrong because several endpoint families intentionally return different errors or null results.

#23424 covers committed target resolution together with the execution-progress gate. This issue covers selector-policy reuse and preservation of endpoint contracts.

## Proposed direction

- Return a typed reason for an unknown, non-canonical, or unsupported-pending selector.
- Reuse one canonical-hash resolution path instead of repeating `HeaderNumber` and `CanonicalHash` reads in handlers.
- Keep endpoint-specific conversion to JSON-RPC errors or null results at the endpoint boundary.
- Keep the current tracing and committed-state error texts unless a deliberate compatibility change is agreed separately.

## Acceptance criteria

- [ ] Endpoint code does not repeat the header-number and canonical-hash comparison sequence.
- [ ] `erigon_getLogs` and `erigon_getLatestLogs` reject non-canonical block hashes instead of scanning the canonical block at the same height.
- [ ] One selector predicate detects `pending`; endpoint families retain their existing response contracts.
- [ ] Tests cover unknown and non-canonical hashes plus `pending` for logs, debug state, tracing, proof, witness, and simulation endpoints.
- [ ] The refactor does not change successful responses or JSON-RPC error codes and messages.

## Related

- #22533
- #23424
- #23416