5. /search/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. The indexer already tracks UTxOs by address. So for `/search/transactions`, **no new chain query logic is needed** — the address is passed through to the existing query pipeline unchanged.

The main work is ensuring the endpoint does NOT reject smart wallet addresses as "invalid", that PLT operations carry the correct token bundle format, and that this is covered by tests so it cannot silently regress.

### Expected Behavior

**`/search/transactions` with smart wallet address:**

```json
// REQUEST
{
"network_identifier": { "blockchain": "cardano", "network": "preview" },
"account_identifier": {
"address": "addr_test1zp5ccj9xxqsx9qnfqa62a086jsggjhqflpduzqa3n7vg3h9afxpncxpaxjsg9k3etntnk8ypdup8ryr6navxyz72c62qh8kcm9"
}
}

// RESPONSE
{
"transactions": [
{
"block_identifier": { "index": 4605891, "hash": "f78faf86..." },
"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 } }
]
}
]
}
}
]
}
}
],
"total_count": 1
}
```

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

**Search by transaction hash** returns a CIP-113 transaction the same as any other transaction. Same pass-through behavior, no schema changes.

**A smart wallet and its owner's base address are separate accounts.** They have different transaction histories — on preview the smart wallet has 1 transaction and the base address 5, overlapping only on the mint. A smart-wallet-to-smart-wallet PLT transfer never touches the base address, so callers resolve the smart wallet address first (#769) and search that.

**Out of scope** — two operation-display changes are tracked as separate issues. Both live in the shared `OperationMapperService` and 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 /search/transactions` accepts a CIP-113 smart wallet address and returns its transactions
- [ ] PLT operations appear with the existing `tokenBundle` metadata format — no new fields added
- [ ] Searching by the hash of a CIP-113 transaction returns it correctly
- [ ] The PLT currency symbol is the hex-encoded asset name including its CIP-68 label prefix
- [ ] A base address does not return transactions that touch only its smart wallet
- [ ] Invalid addresses still rejected (existing behavior preserved)
- [ ] Enterprise/base address searches unaffected (regression check)

Start at the POST /search/transactions entry point and trace its address-validation and existing query pipeline; compare address searches with transaction-hash searches. Add regression coverage for smart-wallet addresses, PLT tokenBundle formatting, invalid addresses, and address-history separation, then verify the existing enterprise/base address behavior remains unchanged.

Written by the indexing model from the issue text.