ListBatches REST path filter silently returns empty on wrong batch_key encoding

[darioAnongba]

Observation

`GET /v1/taproot-assets/assets/mint/batches/{batch_key}` accepts
`batch_key` as a URL-safe base64-without-padding string (grpc-gateway
default for path `bytes`). Any other encoding:

• Hex: silently returns `{"batches": []}`
• Standard base64 with padding: silently returns `{"batches": []}`
• URL-safe base64 with padding: silently returns `{"batches": []}`
• URL-safe base64 without padding: works

The server accepts the request, returns 200, and hands back zero
rows. From a client's perspective this is indistinguishable from
"the batch with that key does not exist."

Impact

The tap-sdk used to send `batch_key` as hex (mirroring the tapcli
output). `WaitForMint` polled `ListBatches --batch-key ` for 60
seconds, always saw zero rows, and timed out. The mint had actually
finalized — we just couldn't see it through this endpoint.

Proposal

• Return 400 with `invalid batch_key: ` when the path
  parameter cannot be decoded, instead of silently succeeding with
  zero rows.
• Optionally accept multiple base64 variants (same fix as the query
  parameter encoding issue).

Context

Found while wiring up the tap-sdk REST client tests in PR #37.