fix(indexer): normalize SDK playlist_contents to canonical {track,time,metadata_time}

[dylanjeffers]

Symptom (prod)

User adds a track to a new playlist: it shows in the UI optimistically, but after a hard refresh the playlist is empty. The on-chain UpdatePlaylist tx landed and was indexed successfully — no error in the indexer logs.

Root cause

A field-name mismatch between the TS SDK and the API readers, introduced when apps#840 cut over playlist indexing from the legacy Python discovery-provider to the vendored `go-openaudio/pkg/etl`.

The TS SDK schema for an UpdatePlaylist entry (apps/packages/sdk/.../playlists/types.ts):

```ts
playlistContents: z.array(z.object({
timestamp: z.number(),
metadataTimestamp: z.optional(z.number()),
trackId: HashId // hashid-encoded string
}))
```

PlaylistsApi runs the metadata through `snakecaseKeys` before signing, so the on-chain metadata carries each entry as:

```json
{"track_id": "", "timestamp": 1700000000, "metadata_timestamp": 1700000000}
```

The legacy Python indexer's `process_playlist_contents` (apps/packages/discovery-provider/.../entities/playlist.py) normalized every entry before persisting:

```python
updated_tracks.append({
"track": track_id, # decoded integer
"time": index_time, # block_integer_time (or prior entry's time)
"metadata_time": metadata_time,
})
return {"track_ids": updated_tracks}
```

ETL's `normalizePlaylistContentsJSON` (added in go-openaudio#265) does NOT replicate this — it only normalizes the outer wrapper to `{"track_ids": [...]}` and `json.Marshal`s the inner entries verbatim. So the JSONB column ends up with `{"track_id": "", "timestamp": ..., "metadata_timestamp": ...}`-shaped entries.

Both API readers in this repo expect the canonical Python shape:

• v1_playlist_tracks.go:46 — `(e.value->>'track')::int` returns NULL when the entry has `track_id` instead of `track`. The JOIN `tracks t ON t.track_id = NULL` matches nothing, and the endpoint returns zero rows.
• dbv1/jsonb_types.go:16 — `PlaylistContents.TrackIDs.Track` is `int64` with JSON tag `track`. Missing field unmarshals as 0, the `TrackMap[0]` lookup misses, and the playlist's `tracks` slice in dbv1/playlists.go:95 comes back empty.

Either path: playlist looks empty even though the row + the `playlist_tracks` junction are correct. (The junction is correct because `pickPlaylistTrackID` does check both `track` and `track_id` and decodes hashids — only the JSONB-write path is missing the normalization.)

Fix

Register an etl `PostHook` for `(Playlist, Create)` and `(Playlist, Update)` that runs in the same DB transaction as the handler. It re-reads the JSONB and rewrites each entry to the canonical shape:

• Resolve `track` (integer): prefer existing `track`, fall back to `track_id`. String values decode via `trashid.DecodeHashId` (same Hashids salt + min length as the upstream junction-table decoder).
• Copy `timestamp` → `time` when `time` is missing.
• Copy `metadata_timestamp` (fallback `timestamp`) → `metadata_time` when missing.
• Drop the SDK-style `track_id`/`timestamp`/`metadata_timestamp` keys after copying their values.

Canonical entries (everything already in the `{track, time, metadata_time}` shape) pass through byte-identical — no spurious UPDATE.

Gated on `params.Metadata["playlist_contents"]` being present — name-only updates don't touch the column. Errors are logged and swallowed per the upstream PostHook contract (no rollback for a failed normalization), mirroring `indexer/user_pubkey_hook.go`.

Why a hook, not an upstream patch + bump

`pkg/etl` is vendored at a `main` pseudo-version per apps#840's pinning policy and lives in the read-only Go module cache. A hook in this repo:

• Lands the fix today on this repo's CI/CD instead of waiting for an upstream PR + version bump.
• Stays surgical: only fixes the column the API readers care about, doesn't touch the junction-table path.
• Is byte-identical no-op for the common case (every entry already canonical).

The same fix should land in `normalizePlaylistContentsJSON` upstream so other consumers of `pkg/etl` get the same correctness. Tracking that as a follow-up.

Test plan

`go test ./indexer/...` — all green (existing tests + 9 new cases):

• `TestPlaylistContentsHook_RenamesSDKShape` — SDK entry `{track_id: , timestamp}` becomes canonical `{track: , time, metadata_time}` with SDK keys removed.
• `TestPlaylistContentsHook_RenamesSDKShape_WithMetadataTimestamp` — Create path with both `timestamp` and `metadata_timestamp` — `metadata_time` comes from `metadata_timestamp`, not `timestamp` (matches Python precedence).
• `TestPlaylistContentsHook_NoChangeForCanonicalEntries` — JSONB byte-identical after hook for the pre-cutover canonical shape.
• `TestPlaylistContentsHook_SkipsWhenMetadataLacksPlaylistContents` — name-only update leaves the JSONB untouched even when it contains fixable entries.
• `TestPlaylistContentsHook_MixedEntries` — only the SDK-shape entry is rewritten; the canonical one passes through.
• `TestPlaylistContentsHook_NumericStringTrackID` — `"12345"` falls back to `strconv.Atoi` (same as `trashid.DecodeHashId`'s Hashids-or-Atoi fallback).
• `TestPlaylistContentsHook_EmptyContents` — `{"track_ids":[]}` (last-track-removed case) untouched.
• `TestPlaylistContentsHook_UndecodableTrackIDLeftAlone` — entry with a malformed track ID is logged and preserved, not silently dropped.
• `TestPlaylistContentsHook_HashidOnTrackField` — hashid string in the canonical `track` slot is decoded too.

`go build ./...` clean, `go vet ./indexer/...` clean.

Out of scope

• The `OPENAUDIO_ETL_ENTITY_MANAGER_DATA_TYPES` env-var gate (if prod set it to a list missing `Playlist`, all playlist handlers would be silently skipped) is not addressed here — that's a config check, not a code fix. Mentioning so reviewers can rule it out by inspecting the deploy.
• The other silent-failure path (`normalizePlaylistContentsJSON` writing `{"track_ids":[]}` for completely unrecognized SDK shapes) isn't addressed here either — by the time a post-hook runs, the original payload is gone. Upstream fix would be needed for that path; doesn't apply to the current prod symptom.

🤖 Generated with Claude Code

[raymondjacobson]

Opting for this instead:
OpenAudio/go-openaudio#321