Pair playlists on their folder path, not their title

[jrgutier]

verify compared some source playlists against the wrong Engine list. Every instance of that invents discrepancies on a conversion that is correct — the worse direction for this tool to fail in, since a verifier that cries wolf gets ignored and the next real defect goes unread.

Found while investigating the "phantom playlist entry" incident. These defects can manufacture that exact symptom (two playlists, one extra track each) on their own, independent of whatever caused the original report.

Three ways it mispaired

#	Defect	Effect
1	title_to_id keyed on title alone, last-write-wins	Two playlists named Chill in different folders collapse onto one list. Engine's uniqueness constraint is per-parent, so this is legal and common.
2	Exact-title lookup succeeds for every same-folder duplicate	The writer renames the second to Name (2), but both source lists still carry the original name — so all N duplicates resolve to list #1. The suffix scan meant to handle this was unreachable.
3	Suffix scan matched startswith("Name (")	A playlist absent from the database resolved to any unrelated list beginning the same way: House was verified against House (old), reported as wrong tracks rather than missing.

One naming implementation

playlist_naming.py now owns the sibling ordering and the rename, used by both the writer that applies the names and the verifier that must predict them.

The two have to travel together: the suffix a duplicate receives depends on the sibling order, so extracting the rename alone would leave verify re-deriving the ordering by hand — the same coupling that produced these defects.

Pairing uses the whole path as a tuple of titles rather than a joined string, because rekordbox permits / in a playlist name; joining is display-only.

⚠️ Breaking change (text output)

Playlist discrepancy keys are now path-qualified:

playlist[Sets/Setlist].track_order    # was: playlist[Setlist].track_order

Nothing parses these keys programmatically (report.py prints d.field verbatim; VerifyResult has no JSON serialization), but scripts grepping verify's output need updating.

A rewritten test — please scrutinize this one

A pre-existing test asserted that a source Main Set should still match a database list retitled Main Set (2), and this PR makes that report as missing instead.

That test was defect #3 in test form. With a single source playlist the writer can never emit a suffix, so that database state means something else modified it — and test_verify_catches_playlist_rename already asserts an external retitle is reported. The old test demanded the opposite outcome for the same operation whenever the new title happened to resemble a rename.

The case it claimed to defend is now covered properly, by a test that builds two same-named playlists and asserts each pairs with the list it actually became.

Verification

• 696 tests (688 before + 8 new), 6 real-stick deselected
• All three defect tests were confirmed red first, for the right reasons
• playlist_naming.py at 100% line + branch coverage; total 87.79% (floor 85%)
• ruff + mypy clean
• Independent review pass: sound; extraction proven behaviour-equivalent to the writer's previous inline grouping

Not included

Remaining workstreams from the investigation are specified in .omc/plans/playlist-phantom-entry-root-cause.md and deliberately left out of this PR: source provenance + torn-file gate + inline pre-publish oracle (W1), external-edit classifier (W3), and the num_rows_large reader probe (W4, needs a real large export.pdb).

🤖 Generated with Claude Code

https://claude.ai/code/session_01V3aF4y4GdsuJta2bfYUZ8w