ListGroups: commit to one canonical group-key encoding in responses

Observation

`ListGroups` returns `map<string, GroupedAssets>` where the map key is
the group key. Today those keys have historically appeared in two
different forms depending on code path:

• 33-byte compressed, serialised as hex (what the current code does).
• 32-byte x-only, serialised as hex (what some legacy paths returned).

The tap-sdk had to land a targeted fix (`parseGroupRefKey`) to
preserve compressed keys through x-only parsing — odd-Y keys get
flipped when round-tripped through Schnorr serialisation, which broke
balance lookups for a fraction of minted groups.

See https://github.com/lightninglabs/tap-sdk/blob/feat/integration-tests/itest/assets.go#L128
for the full workaround.

Proposal

• Commit the API to one encoding in the response (preferably 33-byte
  compressed hex, matching `AssetGroup.tweaked_group_key`).
• Document that invariant in the proto comment.
• Add a test that round-trips odd-Y keys through ListGroups to catch
  regressions.

Why this matters

`ListGroups` is the canonical enumerate-what-I-have API. If the key
representation is ambiguous, every downstream client has to reinvent
the compressed-vs-x-only-case-split logic.

Start by locating ListGroups and its proto comment, then review the tap-sdk assets.go parseGroupRefKey workaround for compressed and x-only keys. Define the response invariant there and add the proposed odd-Y round-trip regression test; done means ListGroups consistently returns the chosen encoding and the test passes.