[Perf] Bundle related entities in /v1/notifications response

[dylanjeffers]

Summary

• Hydrate users/tracks/playlists referenced by /v1/notifications action data inline under a new related block, eliminating the N+1 client round trips currently needed to render notifications.
• Mirrors the pattern already used by the comments endpoints (app.queries.Parallel(...) + data / related envelope).
• Cap actor mining at 1 action per notification group (clients render a single avatar per group, so additional initiator profiles are wasted bytes). Target entities are duplicated across every action in a group, so the cap doesn't drop them.
• Polymorphic fields (*_item_id, content_id, comment entity_id) are routed to tracks vs. playlists by their sibling discriminator (type / content_type / entity_type).
• Pure addition to the response shape — existing clients that ignore related keep working.

Test plan

• go build ./... and go vet ./api/... clean
• CI runs TestV1Notifications_RelatedEntities (covers hydration of users, tracks, playlists; asserts the per-group actor cap bounds a 5-follower fan-out group)
• CI runs the existing TestV1Notifications* suite (response is purely additive — existing assertions on data.notifications.* should still pass)
• Manual sanity check on staging: hit /v1/notifications/{me} and confirm related.users, related.tracks, related.playlists populate for follow / repost / save / comment / tip notifications

Notes

• IncludeUnlisted: true for the parallel hydration — notifications are recipient-personal and may legitimately reference unlisted tracks the user has a relationship with.
• Comment entity_id is folded into related.tracks only when entity_type == "Track". The FanClub and Event entity types don't have a hydrator in Parallel today; clients can keep round-tripping for those until we wire them in.

🤖 Generated with Claude Code