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 <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.

[sergey3bv]

Hey, @darioAnongba I opened a PR to solve the issue, could you please take a look.