fix(restore): preserve PDS blob ref on restored track record (#1319)
caught by manual staging smoke: when restoring a revision that had
audio_storage="both" with a PDS blob ref, the restored PDS record was
being published WITHOUT an audioBlob field, silently dropping the user's
PDS-hosted copy of the audio.
root cause: the restore code explicitly passed `audio_blob=None` to
build_track_record with a misleading comment claiming "PDS blob not
re-uploaded on restore". the comment was right about the blob bytes
(they're already on PDS), but the BLOB REF must still be included in
the new record — PDS records can reference pre-uploaded blobs.
fix: if the revision carries a pds_blob_cid, construct a BlobRef
(using the stored size + the file_type's mime type) and pass it
through to build_track_record. PDS records now keep their audioBlob
field through the full replace → restore round trip.
also adds a regression test that:
- sets up the same scenario the smoke hit (both → replace → restore)
- asserts the published record contains audioBlob pointing at the
original ref
- asserts the live track row keeps audio_storage="both" and the
correct pds_blob_cid / pds_blob_size after restore
note: if the user's PDS has already GC'd the old blob, the record is
still valid — playback falls back to audio_url (R2). we don't re-upload
the blob as part of restore; that would require hauling bytes through
the backend and is out of scope for v1.
Co-authored-by: Claude Opus 4 (1M context) <noreply@anthropic.com>
authored by