feat(oracle): MuzixStreamingOracle consumer routes through Labelton.capTableOf

[Pattermesh]

Summary

Update the consumer-side RoyaltyDistributor (from oracle/SPECIFICATION.md §"Royalty Distribution Integration") to read cap-tables from LABELTON instead of MuzixCatalog. MuzixStreamingOracle itself (#36) is not changed; only its consumer.

Concrete changes

• Add a RoyaltyDistributor contract (new file under src/) that:
  • Reads MuzixStreamingOracle.getLatestRevenue(catalogId) where catalogId == labeltonMasterId (cross-DSP aggregate).
  • Reads Labelton.capTableOf(masterId) for the cap-table.
  • Distributes MUSD (or whichever settlement asset survives the tokenomics rebrainstorm) proportionally.
  • Uses pull-payment + ReentrancyGuard.

Open

• Should catalogId in the oracle be masterId, or variantId? MasterId is the cross-DSP aggregate (DSPs report per recording = ISRC = master). Variant-level accounting would require per-variant ISRC mapping back to a variant id.
• Recommendation: masterId at the oracle level, variant-level accounting only if needed for sync / remix-specific revenue tracking.

Depends on

Part of #38. Depends on companion Labelton.sol PR + #36 (open PR by @abhicris).

cc @abhicris