Classify Engine-added playlists as external edits, not corruption (W3)

[jrgutier]

Implements W3 from .omc/plans/playlist-phantom-entry-root-cause.md. Independent of #9 — nothing here reads a fingerprint or journal, so the two can merge in either order.

Why

verify reported a database Engine DJ had legitimately modified exactly the way it reports corruption:

track library: playlist_count: expected=45 actual=48

Measured on a real 3,673-track stick this session, with the conversion held identical and only Engine's desktop library varied:

Engine desktop library	Playlists after opening Engine	Rows not carrying our epoch
Populated	48 (3 added)	6
Cleared	45 (none added, no row changed)	0

Those extras were Engine syncing its own desktop library — a legitimate feature. Reporting it identically to a corrupt write trains the operator to ignore verify, which is the failure mode this whole line of work exists to prevent.

The discriminator, and why it isn't the id watermark

The plan originally proposed classifying by id watermark — we allocate Playlist.id contiguously 1..N, so anything above N is external. Real hardware disproved that: after the desktop merge, ids ran to 84 against our contiguous 1..45. Engine reassigns ids, it does not merely append.

writer/playlists.py pins lastEditTime to 1970-01-01 00:00:00 on every playlist row it writes. So:

a row whose lastEditTime is not that epoch was not written by rb2engine

and that survives id reassignment. The constant is now public (PINNED_LAST_EDIT_TIME) and imported by verify rather than duplicated as a magic string — re-deriving writer behaviour by hand in verify is what produced the pairing defects in #3.

beyond_watermark is computed for display corroboration only and never gates classification.

Behaviour

• Unexpected playlists carrying a foreign lastEditTime are reported as informational external edits, naming each with its id and timestamp.
• Exit code is untouched. ok still counts only discrepancies; the plan's caveat stands, since an Engine in-place migration rewriting every row would otherwise mass-report.
• playlist_count compares db_count - len(external_edits), so a merge fully explained by Engine emits no discrepancy — while an impostor carrying our epoch still lands in the count.
• Output ends with the remedy: your conversion is not corrupt; re-run convert to make the stick match rekordbox exactly. Consistent with the troubleshooting section shipped in Document what Engine DJ does to a converted library #7.

No laundering — the tests that matter

All five were confirmed to fail against unmodified source before the change:

• extra playlist with a real lastEditTime → external edit, exit code unchanged
• extra playlist carrying our epoch → still a real playlist_count discrepancy
• wrong membership under our epoch → still playlist[...].track_order
• id-reassignment trap: every id shifted +100 with pinned epochs → zero external reports, ok=True
• mixed case: one genuine external + one impostor → external named, discrepancy kept

Verification

709 tests (+5), coverage 88.22% (floor 85), ruff + mypy clean. The 0.4.0 gates (G1d in reader/pdb.py, the pre-publish oracle in writer/build.py) are untouched and their tests pass.

🤖 Generated with Claude Code

https://claude.ai/code/session_01V3aF4y4GdsuJta2bfYUZ8w