Proposal: eth_getCapabilities method

### Summary

Add a discovery method eth_getCapabilities that lets clients advertise what historical coverage their node actually maintains, so users, middleware, and infra can route queries correctly instead of trial-and-error or out-of-band guesses.

This is about data coverage, not feature flags. It answers questions like:
• Which transaction-hash index do you keep (from block X to block Y)?
• Which logs/receipts range do you keep?
• Which canonical block history do you serve?
• Which historical state (world-state) ranges can you answer eth_call/eth_getBalance/eth_getStorageAt for?
• Which trie node history (for proofs/time-travel state) do you keep?

### Motivation

Nodes now run with varied pruning/indexing modes (archive, partial archive, snap-pruned, custom log indexers, state diffs, etc.). Without a standard discovery mechanism:
• Clients spray RPCs that fail unpredictably.
• Load balancers can’t route by capability.
• Users infer coverage from client brand/mode, which is error-prone.

A single, cheap call that returns machine-readable coverage ranges fixes this.