feat(core): schedule auth and content-auth enforcement on audius-mainnet-beta

[rickyrombo]

Why

pkg/core/config/upgrades.go keys activation heights by chain ID and has no entry for audius-mainnet-beta. An unknown chain resolves to an empty schedule, so the rollover build in #553 would run the new chain with no signer enforcement (#450) and no track-cid authorization (#477), and mediorum would never attest a cid. The whole point of activating at the genesis rollover — the replay seeds core_auth_* and a core_auth_cids claim for every migrated track, so enforcement is safe from block 1 — was left unwired.

Follow-on to the genesis migration; merge before the step 3 build in the runbook. Inert on main: nothing changes until prod.json names the new chain.

What

Schedule. audius-mainnet-beta gets AuthEnforcementHeight: 1 and ContentAuthEnforcementHeight: 1. Both, because the content-auth check runs inside validateManageEntityAuth — scheduling content auth alone would silently enforce nothing. Height 1 rather than a later height so no live block is ever produced under the relaxed rules and there is no pre-enforcement window for unverified state to accumulate. audius-mainnet-alpha-beta stays unscheduled, with a comment saying why it must.

Mediorum follows the chain, not the environment. IsContentAuthEnabled(env) was a per-environment list with prod off. Flipping it on would have broken uploads: the same prod build serves the old chain until the rollover, attestations are refused at the mempool before a chain's gate (content attestations are not accepted before content auth is active), and transcode completion fails on attestation error. So the decision moves to config.ContentAuthScheduled(env), which reads the embedded genesis for the environment and asks the schedule for that chain ID. On main prod resolves to audius-mainnet-alpha-beta → off; on #553's branch it resolves to audius-mainnet-beta → on. No separate flag flip, and the two sides cannot disagree.

Side effect worth knowing: stage was in the old list, but audius-testnet-alpha has no gate scheduled, so stage mediorum has been attesting into a chain that refuses attestations. This turns stage off, matching core. If stage should have content auth, it gets a schedule entry, not a list entry.

Verification

• go test ./pkg/core/config/ ./pkg/common/ green; new TestContentAuthScheduledFollowsEmbeddedGenesis pins mediorum's answer to the schedule for every environment's genesis.
• Mediorum upload/preview auth suites green. TestUploadFile, TestUploadPlacement*, TestValidateTusUploadPassesWhenDiskHasRoom fail identically on main (environment-dependent multi-node tests).
• Not yet done, and should be before the bootstrap: re-run the genesis replay verification (runbook Appendix C) on a build that carries both this and build(core): point the prod build at audius-mainnet-beta — *DO NOT MERGE* #553, so the migration replay is exercised with both gates active. Devnet already runs both at height 1, but no integration test replays a genesis-writer artifact.

🤖 Generated with Claude Code

[rickyrombo]

Verification against the 2026-08-25 artifact, run directly on the T7's sealed serve copy (core_genesis_0825_serve) and the replayed ETL (etl_genesis_0825), no node needed:

Check	Count
Current, non-deleted tracks	1,479,455
With a track_cid	1,478,895
track_cid / orig_file_cid / preview_cid with no claim for the owner	0 / 0 / 0
Owners with no core_auth_users row	0

So enforcement at height 1 makes nothing that exists unwritable. The 560 tracks with no track_cid at all are a separate, pre-existing repair question (37 recoverable via audio_upload_id).

End-to-end coverage of the gated path is in the integration test PR that follows this one.