Audited what could have consumed the phantom SOUNDCHECK entry positionally.
Answer: nothing did. The two real consumers of setlist.entries() are safe --
take-segments.py builds a dict keyed by path stem (a phantom adds one unused
key) and migrate-columns.py calls tracks(), not entries(). No shipped artifact
was off by one.

But the audit found a different positional coupling, live and undocumented.
opal_title_map() joins tracks.json's 1..N performance order against
segments_v4.json's perf_track. OPAL was played as 15 tracks; the release cut
Desire, and segments_v4 renumbered around the hole -- its perf_track keys are
1..13 and 15, with no 14. So the join lines up only while Desire still holds
performance slot 14.

Measured both ways rather than argued: as-performed yields 14 mappings
including REVOLUTION; drop Desire to make the page match the release and it
falls to 13. REVOLUTION's title is LOST -- silently, with nothing mislabelled,
which is what would have made it hard to notice. PLN chose as-performed today
as a documentary call about the page; this join quietly depended on the same
answer, and nobody knew the two were connected.

So: the assumption is written down where the join lives, and three tests hold
it -- every released track gets a title, the encore by name, Desire maps to
nothing rather than borrowing a neighbour's, and the hole at perf_track 14 is
still really there. That last one matters: if segments_v4 is ever renumbered
densely the reasoning stops holding, and the right outcome is a red test
rather than a quietly missing track.