Repair the tags on files already recorded: search, a detail pane, and every field the recorder writes

[revtex]

Supersedes #45, which GitHub closed when its base branch metadata-manager was deleted on
merging #44; a closed pull request cannot be retargeted, so this is the same branch, rebased
onto main and reopened. The four commits and their diff are unchanged.

Four commits, and the last three are consequences of the first. Correcting a bad match needed a
search; the search needed somewhere to put its results; and giving the editor that room made it
obvious how few of a file's tags the page could actually reach.

Correcting a match the automatic path cannot reach

There was no way to fix a wrong match. The three fields were editable, so a wrong title could be
typed over — and doing that forfeits the year, the genre and the artwork that come with a real
match, which is most of why anyone opens this page.

Re-fetch could not help, and the reason is structural rather than a bug. The automatic lookup
builds its query from the file's own artist and title, then discards any result whose artist
disagrees with them. Both halves are right: Spotify always returns something, and the top hit for
a misparsed filename is routinely a different song, so the gate is what stops the page writing a
confident wrong answer into a correctly named file. But it means the one case the automatic path
can never reach is a file whose artist is the thing that's wrong — pressing Re-fetch asks the
identical question and gets the identical answer, and Auto-Fetch skips the row entirely because all
three fields are filled in.

Not the right track? is a second lookup with a deliberately different shape from the first: the
user's words instead of the file's, several results instead of a verdict, and nothing filtered on
the way out. A person reading a list can tell a live take from a studio one, and a filter that
could hide the right answer is worse here than a list with a few wrong ones in it. The box is
seeded from the row as it stands, results carry the year so a remaster can be told from the
original, and Use this fills the row in. Nothing reaches a file until Save.

Three decisions there worth the review time:

• The chosen candidate is fetched again through /tracks/{id} rather than tagged from the search
  result. A search result is not a full track — the release date lives on the album and the genre
  on the artist — and a hand-picked match arriving thinner than an automatic one would be a strange
  thing to have built. Both paths share one enrichment step (SpotifyCatalogEnricher).
• Picking a result drops the file's own cover art. The one place the "an embedded picture beats
  a provider's URL" rule is inverted. That rule protects artwork while a lookup confirms what a
  file already says; choosing a different song says the opposite, and keeping the old sleeve would
  write correct tags and the previous artist's cover into the same file.
• Last.fm is not offered here. Its track.getInfo answers a question about a named artist and
  title — a lookup, not a search — so it has nothing to offer someone who doesn't yet know what the
  track is called. An empty box that can never return anything is worse than saying it needs Spotify.

/tracks/{id} is public catalogue data and costs no user scope, so DefaultScopes stays at two and
SpotifyAuthOptionsTests is untouched. CLAUDE.md's call list is updated to six.

The editor moved out of the list row, because it never fitted inside one

The row editor was rebuilt twice and tightened once, and every version was judged by looking at it.
Measuring it settled the question in one reading. At the shell's minimum window the track list
viewport is 347 DIP and one expanded row was 539 — an editor 1.55× the height of the
container it opens in. The page owns only ~130 DIP of the chrome above the list, so spending all of
it still leaves a deficit, and the costed alternative (search in a popover) lands the row at exactly
347, which is the same failure at one decimal place.

So the editor is a pane beside the list. The list holds 5 rows at the minimum window and 11
maximized, the pane is the same size and in the same place whatever is picked, and choosing a
different track reflows nothing — measured at 373 DIP before and after a search returning ten
candidates.

The general rule is worth more than the fix: an expander is usable only when the thing it opens is
smaller than the space it opens into. That is a measurement available before the layout is
written, and it is the check two rebuilds skipped.

Three second-order notes:

• Selection had to come back, and removing it had been right on its own terms. A highlight
  following the arrow keys while nothing acted on the selected row was noise. In a split view the
  selection is the pane's input, so the row has to say which one is showing — a tinted background
  and a narrow accent edge, not the themed container's saturated fill.
• Re-filtering nulls the list's SelectedItem. ApplyFilter clears and refills
  VisibleTracks, and the clear travels out through the two-way binding, so without capturing the
  pick and restoring it the editor emptied on every keystroke in the filter box — including the
  keystrokes narrowing the list toward the row being edited.
• One scroll region was the wrong instinct. Letting the whole pane scroll put ten results below
  the fold, where the only evidence the search had worked was the scroll bar getting shorter. The
  fields scroll; the search box and its results are pinned to the foot.

Every tag the recorder writes is now editable

The page shipped with three editable fields and showed year, genre and artwork read-only beside
them. "Which fields belong here" has an answer that is not a matter of taste: whatever the
recording path writes. FFmpegArguments.MetadataArguments covers title, artist, album artist,
album, genre, date, track, disc and copyright — so a recording could carry a wrong disc number that
no part of Offstream could correct. Composer, comment and BPM are in neither list, which is what
keeps this from drifting into a general-purpose tag editor.

Ten fields do not stack: 10 × 65 DIP is 650 in a 347 DIP pane, the same arithmetic as the section
above, met a day later on the pane that fixed it. Paired into two columns it is 390 — seven of ten
visible at the minimum window, all ten at any real size. Numeric boxes read fine at half width,
which is what makes the pairing free.

Filling the gap turned up three defects underneath it, none visible while the fields were absent:

• Writing one artist back over a tag that held two destroyed data. ID3v2.3 separates artists
  with a slash, so a file recorded as AC/DC holds the two values AC and DC; Read took
  FirstPerformer, the box showed AC, and Write did tag.Performers = [track.Artist] —
  narrowing the tag on the page whose purpose is repairing tags. Pre-existing since the writer was
  written, and invisible until an album artist box appeared beside the artist box showing AC, DC
  next to AC. The original list now goes back verbatim while its first entry still matches the
  box, since that is where the box was filled from; a match satisfies this by construction, because
  the mapper sets the artist from performers[0] — now pinned by a test, as the whole fix leans on
  it.
• The tempting fix there is worse than the bug. Splitting the box on commas the way the genre
  box splits reads Earth, Wind & Fire as three artists. Genres can be edited as a comma-separated
  line because a genre list really is a list; names cannot, because commas inside one name are
  ordinary.
• An emptied box claimed a change it would not make. HasChanges compared before against
  after, so clearing the album box lit Will change and then saved nothing — the writer has never
  written a blank over a value. The predicate now asks whether saving would alter the file, which is
  the question the badge was always claiming to answer.

The never-erase rule became one helper, LibraryLookup, rather than two hand-written copies, and
grew from genre and year to all seven fields a lookup can leave empty. Still two call sites and both
still load-bearing, but the rule exists once — which matters, because the original bug survived its
first fix precisely by existing twice.

A display bug the artwork decision exposed

The thumbnail was bound to decoded bytes — but a lookup normally returns a URL and no bytes, and
the writer downloads it at save time. So it showed the artwork the file already had while claiming
to show what saving would do, and on a hand-picked match it put the replaced track's sleeve on
both sides of the before-and-after. It now binds to either an image or a Uri and lets WPF's
Image.Source fetch the second, which also keeps the network out of the view model and off whatever
thread a fetch happened to finish on.

Every time on this page, the thing that made a bug visible was drawing the value rather than testing
it.

Verification

.\build.ps1 -Clean -Test — 1,269 passing (262 UI + 1,007 Core), 0 warnings. -VerifyFormat
clean. Resource keys 210/210 across en and fr.

Driven in the running app against a real library, because that is where every bug on this page has
come from. The search was exercised on a row tagged AC — Who Made Who against daft punk one more time, an artist the automatic path structurally cannot reach: applying the result rewrote title,
artist and album with a was … line under each, moved the year, and replaced the sleeve on both the
row and the after side. Layout was measured by UIAutomation at the minimum window and maximized
rather than eyeballed.

The save path was verified on a copy of a real recording rather than the library, since Save is
a write to the user's own files: with one unrelated field edited, the file came back with
Performers still AC || DC, the edit applied, and the tag still at ID3v2.3. Before the artist
fix, that same run left AC.

🤖 Generated with Claude Code