UTxO RPC surface: methods where sieve complements cardano-rpc

cardano-node now embeds a gRPC server implementing part of the UTxO RPC (u5c) spec: https://github.com/IntersectMBO/cardano-api/tree/master/cardano-rpc. It deliberately serves only what the node can answer from state it already keeps. Several spec methods need a secondary index, which is exactly what sieve builds. This issue maps the spec surface onto sieve, so the two components can cover the spec together without overlap.

## Methods sieve can implement that the node cannot (without becoming an indexer)

- `SearchUtxos` with payment-part, delegation-part or asset-only predicates. cardano-rpc rejects these as `INVALID_ARGUMENT`: the node has no credential or asset index, so each query would be a full UTxO-set scan. Sieve's selectors (address, payment/stake credential, policy/asset) map onto these predicates almost 1:1, backed by SQLite indexes. Real-world demand exists today: Evolution SDK's u5c provider sends exactly these predicate shapes for `getUtxos(credential)` and `getUtxoByUnit`, and they fail against cardano-rpc.
- `ReadData` (datum by hash). Sieve already serves `/datums/{hash}`, and keeps datums queryable after the carrying output is spent; in the node, spent datums leave ledger state entirely.
- `ReadTx` (transaction by hash). Needs a txid-to-block index that neither component keeps today; sieve could build it cheaply during sync, the node has no natural place for it. Resolving a transaction's inputs also needs the (spent) outputs they reference, which sieve retains and the node's current-state UTxO set cannot answer. (Candidate: sieve's data model stores matches, not full transactions, so this needs an extension.)

## What stays with cardano-rpc (for completeness)

Live ledger state and node internals: `ReadParams`, `ReadGenesis`, `ReadEraSummary`, `ReadState`, `EvalTx`, `SubmitTx`, the mempool methods (`WaitForTx`, `ReadMempool`, `WatchMempool`), and the sync service (`ReadTip`, `FollowTip`, `FetchBlock`, `DumpHistory`). The node also wins on freshness: it answers at the tip, while sieve trails by its sync pipeline.

## Known gap

Sieve currently exposes Kupo-shaped REST; serving the methods above additionally needs a u5c gRPC endpoint (or a translation layer in front). Left out of scope here — this issue is about which methods belong where.

Start by reviewing the UTxO RPC specification and the cardano-rpc surface linked in the issue, then compare its methods with sieve's existing Kupo-shaped REST endpoints, including /datums/{hash}. Done means documenting which methods sieve can cover without overlapping cardano-rpc, while leaving the u5c endpoint or translation layer and the listed node-owned methods out of scope.

Written by the indexing model from the issue text.