rpc: resolve committed block targets and execution progress in one helper

## Problem

Committed state and history handlers commonly call `GetCanonicalBlockNumber` and then `CheckBlockExecuted`. Both operations read Execution stage progress from the same transaction. The second read is redundant, and the separate calls let each endpoint choose the resolution view and gate view independently.

This duplication is small per request, but it makes the committed-view invariant harder to enforce and has already produced inconsistent handling of block tags and header-stage blocks.

#23416 covers atomic view acquisition and propagation. It does not consolidate committed selector resolution with execution validation.

## Proposed direction

Add a focused resolver for state and history consumers that:

- resolves number, hash, and block tags through the exact transaction supplied by the caller;
- requires canonical hashes when requested;
- rejects targets above Execution progress using the progress value already read during resolution;
- returns the concrete number, hash, and latest-state status needed by state-reader construction;
- leaves endpoint-specific error or null mapping at the endpoint boundary.

Keep overlay-backed block-only resolution separate so the helper does not hide the read-view policy.

## Acceptance criteria

- [ ] One Execution progress read is sufficient for committed resolution and validation.
- [ ] `latest`, `latestExecuted`, `safe`, `finalized`, explicit numbers, and canonical hashes have regression coverage.
- [ ] A canonical header above Execution progress returns an error before body, TxNums, history, or state reads.
- [ ] The helper cannot adopt a block overlay when given a committed transaction.
- [ ] Storage and block-reader errors remain distinguishable from unavailable-block results.
- [ ] Existing endpoint-specific JSON-RPC error contracts remain unchanged.

## Related

- #22533
- #23416