fix(indexer): errgroup.WithContext so ETL halt actually exits the process

[raymondjacobson]

Summary

CoreIndexer.Start used a bare errgroup.Group{}, which doesn't share or cancel any ctx. When etlIndexer.Run() returned the halt-on-block-error introduced by go-openaudio#323 / api#883:

• the errgroup captured the error,
• but aggregatesCalculator.Start kept spinning on an uncancelled ctx,
• eg.Wait() blocked forever waiting for it,
• main.go's panic(err) never received anything,
• and the pod stayed 1/1 Running with the ETL goroutine dead.

Observed in prod tonight: a 25P02 cascade in the plays-hook savepoint poisoned the pgx pool, indexBlocks() correctly returned per #323, but the pod kept running. The parity jobs (which startParityJobs launches outside the errgroup) kept ticking, MAX(blocks.height) advanced because the still-running Python indexer was writing them, and health_check looked totally green — making the wedge invisible. The whole point of #323's halt-on-error was defeated by this wrapper.

Fix

errgroup.WithContext(ctx) so the first error cancels gCtx. aggregatesCalculator.Start already has a proper for { select { case <-ctx.Done() ... } } loop and the parity jobs honor ctx via ScheduleEvery, so both exit naturally; eg.Wait() returns, main.go panics, the pod crash-restarts with a fresh pgx pool, and the ETL self-heals on the same block. Same retry semantics #323 promised.

- eg := errgroup.Group{}
+ eg, gCtx := errgroup.WithContext(ctx)
  eg.Go(func() error {
-   return ci.aggregatesCalculator.Start(ctx)
+   return ci.aggregatesCalculator.Start(gCtx)
  })
  eg.Go(func() error {
    ci.logger.Info("Starting ETL indexer")
    return ci.etlIndexer.Run()
  })
- ci.startParityJobs(ctx)
+ ci.startParityJobs(gCtx)
  return eg.Wait()

Caveats (called out in the rewritten comment)

• etl.Indexer.Run() still uses its own internal context.Background(), so when the outer ctx (SIGTERM) is cancelled, gCtx cancels and the aggregates / parity jobs exit, but eg.Wait() still blocks on ETL. The k8s grace-period SIGKILL handles that today — same tradeoff as before, just made explicit.

Test plan

• go build ./..., go vet ./..., gofmt clean.
• go test ./indexer/... still passes (existing pubkey + user_events hook tests).
• After deploy: synthesize an ETL-halt path (or wait for the next transient) and confirm the pod actually crash-restarts instead of going zombie.

🤖 Generated with Claude Code

[raymondjacobson]

Closing for now. The fix in this PR is correct (the bare `errgroup.Group{}` really does block forever when ETL halts), but shipping it on top of the current state would convert today's silent ETL wedge into a continuous pod crashloop during dual-run with Python — see https://github.com/AudiusProject/api/pull/884#issuecomment-… [discussion in PR thread].

The underlying cause is that the on-chain plays bridge from #881 doesn't appear to ON CONFLICT-protect against rows Python has already written, so #883 / go-openaudio#323's halt-on-error fires on essentially every block. That makes #883 incompatible with the dual-run state.

We're rolling back #883 first (and reverting upstream go-openaudio#323) to restore stability, then will audit cross-writer collision points (plays bridge first, anywhere else ETL and Python write the same row second), then re-land #883, then re-land this PR. The diagnosis here stays correct; the deploy sequence isn't.