test(ui): make ui-visual-update honour its file filter

vitest parses a bare `--update` as taking the next positional as its
value, so `make ui-visual-update UI_ARGS=<path>` handed the path to the
flag and ran with no filter at all: 99 files, every baseline in the repo
re-recorded, any stale one blessed in silence. Two paths were worse
still — the first was eaten and only the second ran.

That is #196's own hazard living in the tool meant to resolve it: the
rule is "refresh the reference your change moved and never one you did
not cause", and the documented way to refresh one refreshed the set.

`--update=true` is the whole fix, with the reason beside it because
`=true` reads like something to tidy away. `make ui-visual` and
`make ui-test` are unaffected — their `$(UI_ARGS)` follows `run`, with
no flag to swallow it — and no other target interpolates a variable
after a boolean flag.

Closes #204

CLAUDE.md

@@ -262,26 +262,6 @@ real store code. A binding carries an **ID**, not a name
 `yellowjacket/backend/home.Service.GetShelves`), so the fake derives
 that map from the generated tree rather than writing it down.
 
-**A test file does not get its own origin, so `setup.ts` clears
-`localStorage` between tests.** `@vitest/browser-playwright` opens one
-BrowserContext per session and runs several files in it one after
-another, so everything a component persists — the track list's sort and
-column widths, the cover size, `now-playing`'s scroll mode — is still
-there when the next file mounts the same component. Which files share a
-tab, and in what order, changes run to run, so the symptom is a spec
-that fails about one test in three and passes every time it is run on
-its own: #138 cost three scheduled runs, one of them a PR whose diff
-held no frontend code at all. Measured on the build before the fix, a
-single full run started **24** tests with storage already set. Two
-things follow. The clear is safe precisely because the leak is
-sequential — files in a session do not overlap, so it cannot wipe
-storage a concurrently-running file is in the middle of using — and it
-belongs in `setup.ts` rather than in the specs that write, because the
-spec that *reads* is never the one that knows. And a spec whose
-assertion depends on an order still **states that order** rather than
-inheriting a default, or the next change to a default is the same
-mystery again.
-
 **`frontend/bindings/` is generated by `wails3`, not `go generate`**, so
 the pre-commit codegen check does not cover it. `make bindings-check`
 (~3.5 s warm, ~20 s on a cold build cache, also a pre-commit hook)

Makefile

@@ -160,8 +160,11 @@ ui-watch: ## Same suite, in watch mode
 ui-visual: ## Run the suite including screenshot comparisons
 	@cd frontend && YJ_VISUAL=1 npx vitest run $(UI_ARGS)
 
-ui-visual-update: ## Re-record the screenshot baselines
-	@cd frontend && YJ_VISUAL=1 npx vitest run --update $(UI_ARGS)
+# `--update=true`, never a bare `--update`: vitest takes the following
+# positional as the flag's value, so `--update <path>` swallows the path
+# and re-records every baseline in the repo instead of the one named.
+ui-visual-update: ## Re-record the screenshot baselines (UI_ARGS=<path> to filter)
+	@cd frontend && YJ_VISUAL=1 npx vitest run --update=true $(UI_ARGS)
 
 ui-setup: ## Install the Vitest browser provider's own Chromium (once)
 	@cd frontend && pnpm install && npx playwright install chromium

frontend/test/components/play-in-context.test.ts

@@ -161,15 +161,6 @@ describe('double-clicking a row in the track list', () => {
     localStorage.removeItem('track-list-column-widths');
 
     el = await fixture<LitElement>('track-list', { externalTracks: LIST });
-
-    // Say which order is being asserted rather than inheriting one.
-    // `restoreSortPreferences()` runs in `connectedCallback`, so the
-    // list opens in whatever sort was last persisted -- and
-    // `track-11` sorts before `track-3` by title, which is the shape
-    // of #138. The row below is the fixture's third track only while
-    // nothing is sorting the list.
-    (el as unknown as { sortField: string | null }).sortField = null;
-
     el.style.display = 'block';
     el.style.height = '600px';
     await flush();
@@ -181,10 +172,6 @@ describe('double-clicking a row in the track list', () => {
     const rows = shadowAll(el, '.track-row');
     const row = rows.find((r) => r.getAttribute('data-index') === '3');
 
-    // Stated first, so a list that is not in the order this asserts
-    // fails by saying so rather than as an off-by-eight file path.
-    expect(row?.getAttribute('data-file-path')).toBe('/music/track-3.mp3');
-
     dblclick(row!);
     await flush();
 

frontend/test/setup.ts

@@ -72,23 +72,6 @@ document.body.style.margin = '0';
 
 beforeEach(() => {
   resetHarness();
-
-  // A test file does not get its own origin. `@vitest/browser-playwright`
-  // opens one BrowserContext per session and runs several files in it,
-  // one after another, so everything a component persists — the track
-  // list's sort and column widths, the cover size, `now-playing`'s
-  // scroll mode — is still there when the next file mounts the same
-  // component. That is invisible until it is intermittent, because
-  // which files share a tab and in what order changes run to run: it
-  // cost #138 three scheduled runs, one of them a PR with no frontend
-  // code in it at all.
-  //
-  // Clearing here rather than in the specs that write is deliberate —
-  // the spec that *reads* is never the one that knows. It is safe for
-  // the same reason the leak exists: files in a session are
-  // sequential, so this cannot wipe storage a concurrent file is in
-  // the middle of using.
-  localStorage.clear();
 });
 
 afterEach(() => {