4. /block and /block/transaction - CIP-113 support

### Background

CIP-113 smart wallet addresses are valid Cardano base addresses (just with a script hash as the payment credential), and programmable tokens (PLTs) are native assets at the ledger level. So for `/block` and `/block/transaction`, **no new mapping logic is needed** — PLTs render as ordinary native assets with `tokenBundle` metadata and smart wallet addresses as ordinary bech32 addresses.

The main work is confirming that behavior and covering it with tests so it cannot silently regress. Note that `/block`, `/block/transaction` and `/search/transactions` return the same transaction object via `BlockMapper.mapToRosettaTransactionWithMetadata` and `OperationMapperService` — this issue and # share that code path and differ only in test coverage.

### Expected Behavior

**`/block/transaction` with a CIP-113 transaction:**

```json
// REQUEST
{
"network_identifier": { "blockchain": "cardano", "network": "preview" },
"block_identifier": {
"index": 4605891,
"hash": "f78faf86dfb2d4fe8bc4c0a23ccaa0f75223a5be610e7dbf4e621f31f979584e"
},
"transaction_identifier": {
"hash": "dfd2e3e93ff7b36a4ff9c5c07ec1f8a685ccddeb3258eac6313e82410c35dca2"
}
}

// RESPONSE
{
"transaction": {
"transaction_identifier": { "hash": "dfd2e3e9..." },
"operations": [
{
"operation_identifier": { "index": 3 },
"type": "output",
"status": "success",
"account": { "address": "addr_test1zp5ccj9...qh8kcm9" },
"amount": { "value": "1245590", "currency": { "symbol": "ADA", "decimals": 6 } },
"metadata": {
"tokenBundle": [
{
"policyId": "9cc0471f9cdb97a65efe0e40420b2690bc183a73ebc1c719ac57e181",
"tokens": [
{ "value": "10000000", "currency": { "symbol": "0014df10526f7365747461555344", "decimals": 0 } }
]
}
]
}
}
],
"metadata": { "size": 1458, "scriptSize": 6209 }
}
}
```

The response format is identical to existing `/block/transaction` — no changes needed to response schema. Smart wallet addresses should just be accepted.

The reference transaction above is a CIP-113 registry-insert-plus-mint and exercises the full shape: inputs from a user base address and the registry script address, a withdraw-zero operation, PLT outputs to a smart wallet (CIP-68 labels 333 and 100), registry node NFT movements, and change.

**`/block`** returns the same transaction object embedded in the block response. Same pass-through behavior, no schema changes.

Two operation-display changes are tracked as separate issues. This change behavior for all Plutus transactions, not only CIP-113 ones:

- #780 — filtering zero-value (withdraw-zero) operations. The reference transaction's withdrawal operation is currently exposed with `withdrawalAmount: "0"`.
- #781 — `collateralInput` / `collateralReturn` operations and failed-transaction status handling. Absorbs the generic Plutus collateral rule from #603.

### Acceptance Criteria

- [ ] `POST /block/transaction` for a CIP-113 tx returns all operations with correct amounts and token bundles
- [ ] `POST /block` containing a CIP-113 tx returns the same transaction object as `/block/transaction`
- [ ] Smart wallet addresses appear correctly in input and output operations
- [ ] PLT currency symbols are hex-encoded asset names including the CIP-68 label prefix
- [ ] A block containing both normal and CIP-113 transactions displays both correctly
- [ ] Response format matches existing token bundle format — no new fields added
- [ ] Non-CIP-113 transactions unaffected (regression check)

Start with BlockMapper.mapToRosettaTransactionWithMetadata and OperationMapperService, then inspect the existing /block and /block/transaction test coverage. Add coverage for the supplied CIP-113 transaction shape, including smart wallet addresses and PLT token bundles, and verify that both endpoints return the expected transaction data without changing the response schema.

Written by the indexing model from the issue text.