ListAssets with group_key filter returns empty while ListBalances reports a non-zero group balance

[darioAnongba]

Observation

Reproducible in regtest against tapd main
(`0.7.99-alpha commit=v0.7.0-506-ge5b652e9`) while running the
tap-sdk TestBurnAssetByGroupKey scenario:

1. Mint a grouped fungible asset of 500 units.
2. Burn 100 of them.
3. Mine 6 blocks, wait for `synced_to_chain`.
4. `ListBalances --by-group --group-key ` returns
   `{balance: "400"}`.
5. `ListAssets --group-key ` (default script-key filter)
   returns an empty list.

The wallet demonstrably owns 400 units of the group (the daemon's own
ledger says so) but cannot list a single asset that belongs to it. If
the script-key filter is widened to `--all-script-keys`, the tranche
shows up.

Why this matters

Clients that use the semantic `AssetRef → ListBalances → ListAssets`
flow to enrich a balance with genesis metadata silently fall over
here. The tap-sdk has to either work around it (papering over a
daemon-level inconsistency) or propagate an error that is not true
from the user's perspective.

Proposal

• Default `ListAssets` with a `group_key` filter should surface every
  tranche whose remaining balance contributes to the `ListBalances`
  total, regardless of script-key type. The two RPCs should not
  disagree on "what's in this group."
• If the current behavior is intentional (e.g. burn-output script keys
  intentionally excluded), document the invariant loudly so clients
  stop treating the balance as "there's an asset somewhere."

Context

Found while bringing up parity itests in tap-sdk PR #37. The SDK had a
workaround that I rolled back so the server-side issue stays visible.

[sergey3bv]

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