contests: exclude shadow-banned hosts from /v1/events/remix-contests

[dylanjeffers]

Summary

v1EventsRemixContests (api/v1_events_remix_contests.go) — the endpoint backing the contests discovery page on mobile + web — previously surfaced contests whose host was shadow-banned. v1EventComments already applies the two-signal shadow-ban filter to comment authors; this PR mirrors the exact same pair against contest hosts so the discovery list and comment list stay in lockstep.

This was originally drafted against `packages/discovery-provider/src/queries/get_events.py` in the apps monorepo (PR AudiusProject/apps#14297), but that Flask API was removed in #14236 and the file is dead code on main. Reopening here in the correct repo.

The two signals

Signal	What it catches	Source pattern
aggregate_user.score < 0 (low_abuse_score CTE)	bots, Audius-impersonators, fast-challenge-runners, low-engagement accounts	Same CTE used at v1_event_comments.go:74-76
muted_by_karma CTE	hosts muted by users whose combined follower_count crosses karmaCommentCountThreshold	Same CTE used at v1_event_comments.go:66-73

Both CTEs are lifted verbatim from v1_event_comments.go so the filter is byte-for-byte identical to what the comment system applies to comment authors. Reuses the existing karmaCommentCountThreshold constant (defined at v1_track_comment_count.go:8).

Implementation

Added two CTEs at the top of the SQL, two NOT IN filters to the existing filters slice, and bound the threshold constant:

WITH
muted_by_karma AS (
    SELECT muted_user_id
    FROM muted_users
    JOIN aggregate_user ON muted_users.user_id = aggregate_user.user_id
    WHERE muted_users.is_delete = false
    GROUP BY muted_user_id
    HAVING SUM(aggregate_user.follower_count) >= @karmaCommentCountThreshold
),
low_abuse_score AS (
    SELECT user_id FROM aggregate_user WHERE score < 0
)
SELECT ...
WHERE ...
  AND e.user_id NOT IN (SELECT user_id FROM low_abuse_score)
  AND e.user_id NOT IN (SELECT muted_user_id FROM muted_by_karma)

• The existing u.is_deactivated = false and u.is_available = true filters stay in place. Shadow-ban filtering layers on top.
• The contest's parent track filter (e.entity_type != 'track' OR ...) is untouched.
• The sort priority, pagination, status filter, and entry_counts LATERAL subquery are untouched.
• The users and tracks related lookups downstream are unaffected — they just see fewer rows.

Tests

New TestRemixContestsExcludesShadowbannedHosts test follows the exact pattern of TestRemixContestsExcludesUnavailableContent already in this file. Seeds three contests:

• clean host (score=0, no mutes)
• low-score host (score=-1)
• karma-muted host (muted by a high-follower user crossing the threshold)

Three sub-assertions: only the clean contest is returned; low-score contest absent; karma-muted contest absent.

`go build ./api/...` and `go vet ./api/...` both clean locally. Integration test couldn't be run end-to-end without a local Postgres at port 21300, but the test compiles fine and CI will run it against a fresh DB.

Test plan

• CI green on go test ./api/...
• Manual smoke after deploy: hit /v1/events/remix-contests on staging, confirm a known shadow-banned account's contest no longer appears in the response
• Confirm useAllRemixContests on mobile + web still returns the expected (non-shadowbanned) contests

🤖 Generated with Claude Code