cardano-rpc: replace remaining old cardano-api usage with ledger-direct conversions

[carbolymer]

PR #1247's review established the direction: cardano-rpc reads chain data, so its conversions should consume ledger types directly instead of detouring through the old cardano-api.
That PR migrated script witnesses, auxiliary scripts (ledgerScriptToUtxoRpcScript) and redeemer classification (toPlutusScriptPurposeIndex) to this pattern.
This issue tracks replacing the rest.
The inventory below is initial and will be extended as more usage is found.

Remaining old-API usage

Type/TxOutput.hs - the largest cluster, old-API end to end.
All seven exported functions take or return old-API TxOut CtxUTxO era, UTxO era, Value/PolicyAssets, in both directions.
The encode side is fed from the ledger anyway: txToUtxoRpcTx converts body ^. L.outputsTxBodyL through fromShelleyTxOut purely to satisfy the old-API input type, losing direct access to the ledger reference script (referenceScriptTxOutL) in the process.
The decode side (utxoRpcTxOutputToTxOut -> anyUtxoDataUtxoRpcToUtxo) is a clean, independently migratable chain.
Migrating this module is also the natural place to fix the wire-format bugs in #1246 (address serialised as UTF-8 text instead of raw bytes, inline datum hash populated with datum CBOR), since those live in exactly the conversions a migration rewrites.

Type/Script.hs - legacy encode and decode helpers.
scriptToUtxoRpcScript and simpleScriptToUtxoRpcNativeScript (encode) survive only for referenceScriptToUtxoRpcScript, i.e. the TxOutput pipeline above; they can be deleted once TxOutput's encode side migrates.
utxoRpcNativeScriptToSimpleScript and utxoRpcScriptToReferenceScript (decode) produce old-API SimpleScript/ReferenceScript and follow the TxOutput decode migration.

Type/TxEval.hs - blocked on cardano-api.
The evalTx path runs on the old API by necessity: evaluateTransactionExecutionUnits returns Map ScriptWitnessIndex ... and ScriptExecutionError carries ScriptWitnessIndex; a bridge (scriptWitnessIndexToPlutusScriptPurpose) converts at the seam.
This part cannot migrate until cardano-api's evaluation/fee machinery moves off ScriptWitnessIndex (the experimental fee path currently reuses it internally).

Type/Tx.hs and Type/Certificate.hs - residual conversion helpers.
Individual old-API conversions remain in otherwise ledger-direct code: fromShelleyTxIn, fromShelleyStakeAddr, fromShelleyTxId, fromAlonzoData/getScriptData (datums), fromAlonzoExUnits.
These are small and mostly serialisation-only; each needs a case-by-case check whether a ledger-direct equivalent is available.

Migration approach

Follow the pattern established in #1247: a ShelleyBasedEra era witness, concrete-era dispatch (compile-error tripwire for new eras), ledger lenses and classes, byte-identical wire output verified by old-vs-new equivalence properties.
Note that the experimental API's construction-side types are NOT the replacement for reading paths: AnyScript's plutus representation forces script deserialisation (decodePlutusRunnable), turning total conversions partial - reading code should consume ledger types directly.

Suggested order:

1. TxOutput encode side (ledger TxOut in, includes reference scripts; delete the legacy Script.hs encoders after).
2. gRPC: bytes fields encoded as text or wrong payload (TxOutput.address, Datum.hash) #1246 wire-format fixes, in the same series.
3. TxOutput decode side and the Script.hs decode helpers.
4. TxEval, once the cardano-api prerequisite lands.

Related

• gRPC: bytes fields encoded as text or wrong payload (TxOutput.address, Datum.hash) #1246 - wire-format issues, absorbed by step 2.
• gRPC: Dijkstra era support gaps in UTxO RPC #1263 - Dijkstra era gaps (guard scripts convert gracefully since cardano-rpc: Populate transaction bodies in FetchBlock responses #1247, but the spec cannot represent them).
• cardano-rpc: Populate transaction bodies in FetchBlock responses #1247 - the PR that established the pattern and migrated the first conversions.