feat(jobs/challenges): Phase 1 challenge processors (poll-based)

[raymondjacobson]

Summary

Stacked on #834 (api/parity-jobs).

Implements the discovery-provider "challenges" reward system in api/, replacing apps' Redis event-bus design with a poll-based reconciliation model (Option C from the earlier architecture discussion). Each Phase 1 challenge has its own `Processor` that reads source tables on a tick and writes derived state into `user_challenges` + per-challenge state tables.

Why poll-based

• Idempotent / restart-safe / backfill-friendly by construction. A fresh DB rebuilds full state on first scan; a crash mid-batch leaves nothing inconsistent.
• No producer coupling. entity_manager handlers (in pkg/etl, soon-to-be-vendored) don't need to know challenges exist. Same architectural boundary as the agreed-upon Populate data from $AUDIO specific tables to mint agnostic tables #267 split.
• No Redis dependency introduced. Drops one moving part.
• Consistency parity with apps. Apps' challenge processing is already async (Redis-backed, rate-limited); we're just batching differently.

Phase 1 challenges (11 in 7 processor files)

ID	Source	Notes
`p`	`users` + `follows` + `saves` + `reposts`	7 boolean steps; also updates `challenge_profile_completion`
`u`	`tracks`	3 public non-stem tracks since starting_block
`fp`	`playlists`	Boolean — any non-deleted playlist
`v`	`users.is_verified`	Boolean
`e`	`plays` (checkpoint-incremental)	Endless streak; currently `active=false` in catalog
`p1`/`p2`/`p3`	`aggregate_monthly_plays`	Verified artists; 250/1k/10k; p2 gates on p1, p3 on p2
`tt`/`tut`/`tp`	`track_trending_scores` / `playlist_trending_scores`	Fridays UTC; idempotent same-week; rank-tiered amounts

Architecture

`api/jobs/challenges/processor.go`:
```go
type Processor interface {
ChallengeID() string
Reconcile(ctx context.Context, tx pgx.Tx) error // idempotent
}
```

`api/jobs/index_challenges.go` is the umbrella job:

• Runs each processor in its own `pgx.Tx` (one bad processor doesn't kill the rest).
• Scheduled via `ScheduleEvery(ctx, 30*time.Second)` in `CoreIndexer.startParityJobs`.

Common helpers in `processor.go`:

• `LoadChallenge` — read catalog row by id.
• `UpsertUserChallenge` — preserves `completed_at` once set; sticky `is_complete`.
• `SpecifierFromUserID` — matches Python's `hex(user_id)[2:]`.

Migration

`ddl/migrations/0203_seed_phase_1_challenges.sql` seeds the catalog rows from `challenges.json`. `ON CONFLICT DO UPDATE` matches apps' `create_new_challenges.py` behavior so the catalog stays aligned even if rows already exist.

Out of scope (called out)

• Trending notifications + tastemaker challenge dispatch — depend on the event-bus mechanism we explicitly skipped.
• Send-tip / audio-matching (`b`, `s`) — Solana.
• Mobile install (`m`), one-shot (`o`), referrals (`r`, `rv`, `rd`) — need a client-reported signals endpoint (Phase 3).
• First weekly comment (`c`), cosign (`cs`), pinned comment (`cp`), remix contest winner (`w`), tastemaker (`t`) — Phase 2.

Test plan

12 DB-backed tests against the `test_jobs` template DB:

• `TestTrackUpload_CompletesAt3` — 3 tracks → complete
• `TestTrackUpload_IgnoresStemsAndUnlisted` — only public non-stem tracks count
• `TestFirstPlaylist_CompletesOnAnyPlaylist` — boolean completion + correct amount
• `TestProfileCompletion_PartialProgress` — 3/7 reflected accurately
• `TestProfileCompletion_FullyComplete` — 7/7 marks complete
• `TestProfileVerified_CompletesForVerifiedUsers` — verified-only
• `TestListenStreak_SkippedWhenInactive` — no-op when catalog row is inactive (current default)
• `TestListenStreak_AdvancesAcrossDays` — activated; streak increments across 16h+ gaps
• `TestPlayCount250_RequiresVerified` — non-verified users skipped
• `TestPlayCount1000_GatedOnPrevious` — p2 only fires after p1 complete
• `TestTrending_IdempotentSameWeek` — Friday-only; second run no-ops
• `TestTrending_SkipsNonFriday` — gated weekday check

All 12 pass; `go build ./...` clean; `go vet ./...` clean.

🤖 Generated with Claude Code