logan
dfb338fc37
`fixtures.md` told an agent the WAV fixtures scan in untitled, that there is no "Field Recordings" artist in the Artists view, and that this is a known open bug "pinned by TestWAVTagsAreNotReadableYet" — a test #104 deleted, because it existed to assert the reader did not work and failed the moment it did. That last clause is why this is worth a diff rather than being left to rot: the paragraph is an instruction, and it instructs the next reader that a spec asserting the *working* behaviour is the mistake. It is the same #104 staleness #217 removed from `queue-selection.spec.ts`, one file over, still telling agents to put it back. Measured against a running app rather than corrected from the issue text — and the seed had to be rebuilt first, since the one on disk predated #104 and would have replayed a pre-#104 scan and confirmed the stale paragraph. On a fresh `make sandbox-seed NAME=default`, both WAVs carry a title, an artist credit and an album: "Field Recordings" is an ordinary artist with 2 tracks and "Test Tones" has a cover row. The only two tracks with no album at all are `unsorted/no-tags-at-all.mp3` and `unsorted/title-only.mp3`. The replacement also says that prose written before #104 disagrees, because it does, and saying nothing is how the next reader reintroduces the claim from a source this change deliberately does not touch. Deliberately carries no `Closes` footer. #225 covers two halves, and the second — the same staleness in two *dated* `.planning/NOTES.md` entries — is left alone: whether measured history gets a correcting clause is a judgement about what that file is for, which the issue raises on purpose and this change must not settle by auto-closing it.