test(integration): cover content authorization end to end on the devnet

[rickyrombo]

Why

Content authorization (#477, #476) had thorough unit coverage and no end-to-end coverage: nothing uploaded audio with an asserted user, waited for the validator's attestation, and then tried the track writes that enforcement exists for. The devnet activates both AuthEnforcementHeight and ContentAuthEnforcementHeight at height 1, and CI runs make test-integration against it, so this now runs on every PR.

What it checks

Uploads go to node 2, writes go to node 1. Claims are consensus state, so a node that never saw the bytes must still enforce them.

1. An audio tus create with no userId is refused with 400 — it could never be attested, so fail before the bytes are sent.
2. After the upload reads done, the owner's track create naming track_cid and orig_file_cid is accepted. done is only written after the attestation commits, so this is the ordering guarantee under test.
3. Another user creating a track with the same cids is rejected: was not uploaded for user.
4. The owner creating a track with a never-uploaded cid is rejected: is not attested to any uploader.
5. An edit that resends the cids is accepted — the web client resends every cid field on a metadata edit, so this is the common path.
6. A metadata-only edit is accepted.

Track updates are not projected at consensus (ownership on update is the ETL's rule), so 5 and 6 exercise the content-auth check alone.

Verified

Green against a devnet built from current main (88de83c9), 12.7s. On a devnet whose nodes 2–4 ran the image from before #570, case 2 failed with done and no 320 result — the exact race #570 fixed — so the test discriminates.

Along the way: the multipart /uploads path and the Go SDK's UploadFilesTus carry no userId, so neither can produce a claimable audio upload on a gated network. The JS SDK does. Worth a follow-up if the Go SDK is meant to upload audio.

🤖 Generated with Claude Code