ListBatches REST path filter silently returns empty on wrong batch_key encoding

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 <hex> 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: <detail> 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.

Locate the REST handler for GET /v1/taproot-assets/assets/mint/batches/{batch_key} and reproduce requests using hex and the three base64 variants described. Trace how invalid path decoding becomes an empty result. Done means invalid encodings return HTTP 400 with an error identifying the invalid batch_key, with coverage for the observed cases.