feat(storage): attribute multipart, gRPC, and Go SDK uploads to a user

[rickyrombo]

Stacked on #574 (base is its branch); the review diff is this change alone.

Why

Only the tus path read the userId that mediorum attests cids to (#476). Audio sent through POST /uploads, the UploadFiles RPC, or either Go SDK helper produced uploads no user could claim, so a track naming their cids is rejected on any network that enforces content authorization. The JS SDK was fine; the Go SDK and every multipart client were not.

What

• POST /uploads and UploadFiles read an optional userId (form field / new user_id proto field) through resolveOptionalUploadUserID and set it on the upload row, so transcode completion attests exactly as it does for tus. A malformed id is rejected with 400, as on tus.
• Optional, not required. These paths serve programmable distribution: a DDEX release names parties, not users, and creates its tracks through Release transactions that content auth never gates. Requiring a user id here would break deliveries for nothing. What an unattributed audio upload gives up is only the claim. The rationale is on the helper.
• UploadFilesRequest.user_id added; UploadFilesTus forwards it as tus metadata; UploadOptions.UserID writes the multipart field; examples/upload sets it for the user it creates the track as.

Verification

• Unit: two tests on the optional resolver (absent allowed under enforcement; malformed rejected; images ignored).
• Integration, on a devnet built from this branch (28s, all green): test(integration): cover content authorization end to end on the devnet #574's six cases plus GoSDKMultipartUploadIsClaimable and GoSDKTusUploadIsClaimable, each uploading through the SDK path with a user id and then creating a track naming the resulting cids on a different node.

🤖 Generated with Claude Code