fix(settings): stop offering a column the backend rejects

Settings -> Track List Columns listed two rows both called "Track
Name", one of which could not be ticked, and a screen reader heard
"Show the Track Name column" twice with nothing to tell them apart.

They are `titleArtist` and `trackName`, and the issue left open which
way to fix it: a second label so the sort dropdown and the configurator
can say different words, or drop the row because the user cannot select
it. The code settles that. `titleArtist` is not in
`tracklist.AllColumnIDs`, so `Config.Validate()` returns `unknown
track-list column ID: "titleArtist"` -- ticking the row sends a column
set the backend rejects, `config-page` swallows the rejection into a
`console.error`, and the tick reverts. A second label would have named
a control that cannot work.

So a definition says whether it is a *choice*, and the configurator
reads `CONFIGURABLE_COLUMN_IDS` rather than `Object.keys(COLUMN_DEFS)`.

The new test reads Go's own list out of `backend/tracklist/config.go`
rather than writing it down a third time, since a third copy is the
fault one step earlier. Verified by planting: with the filter removed
all four assertions fail with the defect's own numbers.

Not fixed here, and filed as #231: `SetTrackListColumns` assigns before
it validates, so a rejected list stays in memory and `Save()` validates
the whole config -- one tick and no setting saves for the rest of the
session. That is reachable from any invalid input, not from this row.

Closes #197

CLAUDE.md

@@ -1486,6 +1486,28 @@ live**: a scrim over a menu item is that item's text surface, and the
 14px spends its weight below the last legible label, measured at 9.9:1
 on the light ramp, whose `bgElevated` is `#e9ecef`.
 
+**And the phone has two sheets, so that rule is one file both read**
+(#210). `bottom-nav`'s "More" is capped at the same 85vh and overflows
+for the same reason — measured at 424x439 with eight destinations,
+`scrollHeight` 412 against `clientHeight` 373, and eleven items at 48px
+would be 528, since #25 makes the count the user's. So the two layers
+live in `styles/sheet-scroll.css.ts` and each host says only what is
+local to it: the colour, handed over as `--yj-sheet-surface` on the same
+box, because the nav sheet paints the sidebar's `--yj-bg-surface` and
+the context sheet the menus' `--yj-bg-elevated` — a shared rule that
+hard-coded either would draw that seam across the other one.
+
+The half that is not the fade is what makes it visible: **nothing inside
+the sheet may repaint the surface**, because these are background layers
+on the scroller and an opaque child covers them. `menu-surface` already
+had it from the other side (`.context-menu-panel[data-sheet]` is
+`background-color: transparent`); `app-sidebar`'s host paints
+`--yj-bg-surface`, which in the shell is its own background and in the
+sheet is a second copy of the sheet's, so `bottom-nav` turns it off.
+Measured at 424x439 with the fade adopted and that rule missing: a flat
+52,58,64 to the bottom edge with 39px still below, which is the defect
+unchanged and every assertion about `background-attachment` passing.
+
 **The playlist submenu is a sheet too, and it had to be.** It is a
 `placement="right-start"` flyout, and making the menu full-width moved
 its anchor — measured at x −182 to 0, entirely off-screen, so "Add to
@@ -1848,6 +1870,21 @@ is not it.** A `placeholder` is an accname fallback, so an
 Explore's search box — the audit's own `a11y.26` — as clean. A sweep
 for *empty* names cannot see a *weak* one.
 
+**`title` is the same trap one rung lower, and it defeats the obvious
+spec as well as the obvious sweep.** `queue-panel`'s Clear queue and
+Add queue to playlist were named by `title` alone, so
+`getByRole('button', { name: 'Clear queue' })` matched them **before**
+the fix as well as after — a `getByRole` assertion, which is what
+catches every other nameless control in this app, would have been
+green on the broken build. `title` is the *last* fallback in the
+accname order, so content put inside the button later silently
+outranks it, and it is the one name a phone cannot show, having no
+hover. The property is therefore asserted as *the name is not the
+tooltip*: `queue-overlay.spec.ts` removes the `title` attributes and
+asks again, which is 1 and 1 with `aria-label` and was measured at 0
+and 0 without it. The `title`s stay, because on a desktop they are
+also the tooltip for an icon-only control and that is a different job.
+
 **The shell scrolls sideways and not down.** `body` is
 `overflow-x: auto; overflow-y: hidden`, and both halves are measured.
 Vertically there is nothing to fix: the middle grid row is `1fr` and
@@ -3238,6 +3275,27 @@ its own duplicates apart) — and changing either is invisible against an
 existing `YJ_HOME`, whose `config.toml` already holds the old list, so
 `make sandbox-seed NAME=default` before believing the app.
 
+**And the *valid* columns are declared twice too, which is the pair
+that drifted.** `tracklist.AllColumnIDs` is what the backend accepts;
+`COLUMN_DEFS` is what the frontend knows how to draw, and they are not
+the same set — `titleArtist` is a definition and not a choice, since it
+is the phone's stacked column and is picked by width in
+`PHONE_COLUMN_IDS`. Settings built its list from `Object.keys(
+COLUMN_DEFS)` and so offered it: **two rows both called "Track Name"**
+(#197), the second unselectable, because ticking it sends a column set
+Go rejects with `unknown track-list column ID` and `config-page`
+swallows that into a `console.error`. `CONFIGURABLE_COLUMN_IDS` is what
+the configurator reads now, derived from a `configurable` flag on the
+definition, and `settings-column-list.test.ts` reads Go's own list out
+of the source rather than writing it down a third time — the rule being
+about every column, so checking one checks nothing.
+
+One thing it does **not** fix, because it is reachable from any invalid
+input rather than from that row: `SetTrackListColumns` assigns before it
+validates, so a rejected list stays in memory and `Save()` validates the
+whole config — one tick and **no setting saves for the rest of the
+session**, silently. That is #231.
+
 **Event-driven communication**: Backend emits events via Wails runtime; frontend stores subscribe to them. Event names are constants in `backend/events/`.
 
 `frontend/src/events.ts` is **generated** from `backend/events/events.go`

backend/riff/riff.go

@@ -63,12 +63,15 @@ func Parse(r io.Reader) ([]Chunk, error) {
 			return nil, err
 		}
 
-		data := make([]byte, size)
-		if _, err := io.ReadFull(r, data); err != nil {
+		// Copied rather than allocated up front, as ID3Chunk does: the
+		// size is four bytes off the file, so a truncated one is free to
+		// declare a chunk larger than the whole of itself.
+		var data bytes.Buffer
+		if _, err := io.CopyN(&data, r, int64(size)); err != nil {
 			return nil, fmt.Errorf("read chunk data for %q: %w", id, err)
 		}
 
-		chunks = append(chunks, Chunk{ID: id, Data: data})
+		chunks = append(chunks, Chunk{ID: id, Data: data.Bytes()})
 
 		// Odd-length chunks have a padding byte.  Lenient: if the
 		// read fails (e.g. EOF), just break rather than error.

backend/riff/riff_test.go

@@ -4,6 +4,7 @@ import (
 	"bytes"
 	"encoding/binary"
 	"errors"
+	"runtime"
 	"testing"
 
 	"yellowjacket/backend/riff"
@@ -209,3 +210,45 @@ func TestParse_ReadsEveryChunkInOrder(t *testing.T) {
 		t.Errorf("odd chunk data: got %q, want %q", chunks[1].Data, "INFOodd")
 	}
 }
+
+// A chunk size is four bytes read off the file, so a truncated or
+// malformed WAV is free to declare a chunk larger than the whole of
+// itself.  Parse must grow with what arrives rather than with what was
+// claimed.
+//
+// This measures the allocation instead of the error because the error
+// is the same either way: a build sizing its buffer from the header
+// reports the truncation correctly, having asked the allocator for a
+// gigabyte on the way.  Deliberately not parallel — TotalAlloc is
+// process-wide, and a test paused beside another one is measuring it
+// too.
+func TestParse_DoesNotAllocateWhatAChunkClaims(t *testing.T) {
+	// Large enough that a header-sized buffer is unmistakable, in a
+	// container of a few dozen bytes.
+	const declared = 1 << 30
+
+	var raw bytes.Buffer
+
+	raw.WriteString("RIFF")
+	_ = binary.Write(&raw, binary.LittleEndian, uint32(declared+12))
+	raw.WriteString("WAVE")
+	raw.WriteString("data")
+	_ = binary.Write(&raw, binary.LittleEndian, uint32(declared))
+	raw.WriteString("and then the file ends")
+
+	var before, after runtime.MemStats
+
+	runtime.GC()
+	runtime.ReadMemStats(&before)
+
+	if _, err := riff.Parse(bytes.NewReader(raw.Bytes())); err == nil {
+		t.Fatal("Parse: got nil error for a chunk larger than the file holding it")
+	}
+
+	runtime.ReadMemStats(&after)
+
+	if grew := after.TotalAlloc - before.TotalAlloc; grew > 1<<20 {
+		t.Errorf("Parse allocated %d bytes reading a %d-byte file whose chunk header claimed %d",
+			grew, raw.Len(), declared)
+	}
+}

e2e/specs/queue-overlay.spec.ts

@@ -157,6 +157,62 @@ test.describe('an overlaid queue says it is over the content', () => {
   });
 });
 
+/**
+ * #170 — the other two buttons in that same row.
+ *
+ * Clear queue and Add queue to playlist predate the close button and
+ * were named by a `title` attribute and nothing else. Unlike the
+ * sliders in `control-names.spec.ts`, that is not a *missing* name:
+ * `title` is the last fallback in the accname order, so
+ * `getByRole('button', { name: 'Clear queue' })` matched them before
+ * this fix as well as after it — measured, 1 and 1. A sweep for empty
+ * names cannot see a weak one, which is `a11y.26`'s complaint and the
+ * reason this file could have grown a green test that proved nothing.
+ *
+ * So the name is asserted twice, and the second assertion is the one
+ * that fails on the broken build. Taking the tooltip away and asking
+ * again is the property in words: **the name is not the tooltip**. It
+ * is what makes the button survive content being put inside it later,
+ * and it is the only one of the two a phone has — there is no hover on
+ * the surface #55 turned into a full screen. Measured on `main` before
+ * the fix: 0 and 0.
+ *
+ * Both buttons are disabled here, because the queue starts empty and
+ * naming is not enablement. A disabled button is still in the
+ * accessibility tree, which is exactly where the complaint was.
+ */
+test.describe('the queue header says what its actions do', () => {
+  const ACTIONS = ['Clear queue', 'Add queue to playlist'];
+
+  test('names both of the older actions', async ({ app }) => {
+    await openQueue(app);
+
+    for (const name of ACTIONS) {
+      await expect(
+        app.getByRole('button', { name, exact: true }),
+      ).toHaveCount(1);
+    }
+  });
+
+  test('and the names do not come from the tooltip', async ({ app }) => {
+    await openQueue(app);
+
+    await app.locator('#queue-panel').evaluate((el) => {
+      for (const button of el.shadowRoot!.querySelectorAll(
+        '.header-action-button',
+      )) {
+        button.removeAttribute('title');
+      }
+    });
+
+    for (const name of ACTIONS) {
+      await expect(
+        app.getByRole('button', { name, exact: true }),
+      ).toHaveCount(1);
+    }
+  });
+});
+
 /**
  * The inline panel is the mode that already worked, and the one every
  * other queue spec is written against. It keeps its resize handle and

e2e/specs/queue-selection.spec.ts

@@ -103,12 +103,17 @@ async function queueSixAndOpen(app: Page): Promise<void> {
      *
      * `explore-link` routes a track name to its *album's* page, so a
      * track with no album renders a name that navigates nowhere — and
-     * the fixture library deliberately contains two (`01 Tone A`,
-     * `02 Tone B`). Which tracks arrive first is `audio_files.id`
-     * order, i.e. the order the **scan** inserted them, which depends
-     * on concurrency and directory traversal: locally the first eight
-     * all had albums and the spec passed twice over, and CI rebuilds
-     * its seed with a real scan and got a different eight.
+     * the fixture library deliberately contains two,
+     * `unsorted/no-tags-at-all.mp3` and `unsorted/title-only.mp3`.
+     * (It contained four until #104: the two WAVs under `Field
+     * Recordings/Test Tones` had been tagged on disk all along and
+     * scan in with their album now, so they are ordinary tracks and
+     * not examples of this.) Which tracks arrive first is
+     * `audio_files.id` order, i.e. the order the **scan** inserted
+     * them, which depends on concurrency and directory traversal:
+     * locally the first eight all had albums and the spec passed twice
+     * over, and CI rebuilds its seed with a real scan and got a
+     * different eight.
      *
      * Asking for what the test needs is the fix. It is not a
      * narrowing: every assertion here wants an ordinary track, and

frontend/src/components/bottom-nav/bottom-nav.ts

@@ -4,6 +4,7 @@ import '@awesome.me/webawesome/dist/components/icon/icon.js';
 import '@awesome.me/webawesome/dist/components/drawer/drawer.js';
 import type WaDrawer from '@awesome.me/webawesome/dist/components/drawer/drawer.js';
 import { designTokens } from '../../styles/tokens.css';
+import { sheetScrollFade } from '../../styles/sheet-scroll.css';
 import '../sidebar/app-sidebar.js';
 import { nameDialog } from '@utils/name-dialog';
 import { ICON_PLAYLIST } from '@utils/icon-language';
@@ -167,6 +168,15 @@ export class BottomNav extends LitElement {
             overflow: hidden;
         }
 
+        /* And this list does not fit (#210): measured at 424x439 with
+           the seed's eight destinations, the body is scrollHeight 412
+           against clientHeight 373, and eleven items at 48px would be
+           528 -- the count is the user's since #25. So the sheet says
+           where the fold is, with styles/sheet-scroll.css's two layers
+           rather than a second answer to the question #207 settled for
+           the context sheet. The colour is the local half: the sidebar
+           paints --yj-bg-surface, so the cover does too, or the fade
+           draws the menus' grey across the bottom of this one. */
         wa-drawer::part(body) {
             padding: 0;
             /* A scroll that reaches the end of this list must not
@@ -177,6 +187,23 @@ export class BottomNav extends LitElement {
                on a gesture-navigation phone -- the same allowance the
                bar itself makes above. */
             padding-bottom: env(safe-area-inset-bottom, 0);
+            --yj-sheet-surface: var(--yj-bg-surface, #212529);
+            ${sheetScrollFade}
+        }
+
+        /* And the sheet paints that surface once. The sidebar's host
+           paints the same grey -- which in the shell is the sidebar's
+           own background and here is a second, opaque copy of the
+           sheet's, drawn *over* the body's layers. So the fade was
+           painted and then covered: measured at 424x439 before this
+           rule, the last 32px read a flat 52,58,64 with 39px still
+           below. menu-surface meets the same requirement from the
+           other side, where .context-menu-panel[data-sheet] is
+           background-color: transparent; nothing changes visually
+           here, because the colour underneath is the one being
+           removed. */
+        app-sidebar {
+            background-color: transparent;
         }
 
         /* A sheet is dragged at with a thumb, so it says where its top

frontend/src/components/config-page/config-page.ts

@@ -51,7 +51,7 @@ import type { BackgroundShade } from '@store/theme-store';
 import type { IconStyle } from '@store/favorites-store';
 import {
     COLUMN_DEFS,
-    ALL_COLUMN_IDS,
+    CONFIGURABLE_COLUMN_IDS,
 } from '@components/track-list/columns';
 
 import './config-field';
@@ -1640,7 +1640,7 @@ export class ConfigPage extends ViewLifecycleMixin(LitElement) {
             ...this.trackListCtrl.columnIds,
         ];
 
-        const disabledIds = ALL_COLUMN_IDS.filter(
+        const disabledIds = CONFIGURABLE_COLUMN_IDS.filter(
             (id) => !enabledIds.includes(id),
         );
 

frontend/src/components/menu-surface/menu-surface.ts

@@ -65,6 +65,7 @@ import '@awesome.me/webawesome/dist/components/popup/popup.js';
 import '@awesome.me/webawesome/dist/components/dialog/dialog.js';
 import type WaPopup from '@awesome.me/webawesome/dist/components/popup/popup.js';
 
+import { sheetScrollFade } from '../../styles/sheet-scroll.css';
 import { PHONE_QUERY } from '@utils/breakpoints';
 import { nameDialogsIn } from '@utils/name-dialog';
 
@@ -164,46 +165,17 @@ export class MenuSurface extends LitElement {
            and worse when the cut lands on a row boundary, where the
            sheet ends in a clean edge that reads as the end of the list.
 
-           Two layers, and the *order* is what asks the question: a
-           shadow pinned to the bottom of the box (attachment scroll),
-           and over it a cover of the sheet's own colour painted at the
-           end of the *content* (attachment local), which therefore
-           scrolls up over the shadow and hides it exactly when there is
-           nothing more to see. So the affordance is absent on a menu
-           that fits, present the moment one does not, and gone again at
-           the end of the list -- with no scroll listener, no
-           measurement, and nothing reaching into wa-dialog's shadow
-           root for the scroller. background-attachment is Chrome 4;
-           the reference device is Chrome 113.
-
-           **The curve is steep because the rows under it stay live.**
-           A scrim over a menu item is that item's text surface, and
-           this app's rule is that text clears 4.5:1 on every surface it
-           can sit on -- which the light ramp, whose bgElevated is
-           #e9ecef, is what makes non-theoretical. A row is 48px with
-           its label centred, so 32px of scrim that is already down to
-           a quarter strength at 14px reaches y-centre at about 0.06 and
-           spends its weight on the strip below the last legible label.
-           Measured on the dark ramp at x=300, flat 52,58,64 throughout
-           before: 50,56,62 at y=330, 33,37,40 at y=350 and 22,24,27 at
-           the bottom edge, and flat again at the end of the list. The
-           light ramp puts 9.9:1 on the last label. */
+           The two layers that say it live in styles/sheet-scroll.css
+           (#210), because the phone has a second sheet -- bottom-nav's
+           "More" -- which overflows for the same reason and must not
+           arrive at its own answer for what a fold looks like. What is
+           local to this sheet is the colour the cover is painted in:
+           the menus' elevated grey, handed over as --yj-sheet-surface
+           on the same box. */
         wa-dialog::part(body) {
             padding: 0;
-            overflow-y: auto;
-            background:
-                linear-gradient(
-                        var(--yj-bg-elevated, #343a40),
-                        var(--yj-bg-elevated, #343a40)
-                    )
-                    bottom / 100% 32px no-repeat local,
-                linear-gradient(
-                        to top,
-                        rgba(0, 0, 0, 0.6) 0%,
-                        rgba(0, 0, 0, 0.25) 45%,
-                        rgba(0, 0, 0, 0) 100%
-                    )
-                    bottom / 100% 32px no-repeat scroll;
+            --yj-sheet-surface: var(--yj-bg-elevated, #343a40);
+            ${sheetScrollFade}
         }
 
         /* A sheet is dragged at with a thumb, so it says where its top

frontend/src/components/queue-panel/queue-panel.ts

@@ -2201,11 +2201,25 @@ export class QueuePanel
                             `
                             : nothing}
                     </div>
+                    <!-- **Every action here is named by aria-label**, like
+                         the close button #24 added beside them (#170). A
+                         title alone *is* a name, which is why a sweep for
+                         empty names reports these clean and why an
+                         assertion by role and name is green either way --
+                         but it is the weakest one: title is the last
+                         fallback in the accname order, so any content put
+                         inside the button later silently outranks it, and
+                         a phone has no hover to show it as a tooltip.
+
+                         The titles stay. On a desktop they are the tooltip
+                         for an icon-only control, which is a different job
+                         from naming it, and aria-label does not do it. -->
                     <div class="header-actions">
                         <button
                             class="header-action-button"
                             @click=${() => void this.handleClearQueue()}
                             ?disabled=${tracks.length === 0}
+                            aria-label="Clear queue"
                             title="Clear queue"
                         >
                             <wa-icon
@@ -2216,6 +2230,7 @@ export class QueuePanel
                             class="header-action-button add-to-playlist-button"
                             @click=${this.handleAddToPlaylist}
                             ?disabled=${tracks.length === 0}
+                            aria-label="Add queue to playlist"
                             title="Add queue to playlist"
                         >
                             <wa-icon

frontend/src/components/track-list/columns.ts

@@ -32,6 +32,18 @@ export interface ColumnDef {
     id: string;
     /** Human-readable header label. */
     label: string;
+    /**
+     * Whether Settings may offer this column. Defaults to true.
+     *
+     * A definition is not the same thing as a *choice*. `titleArtist`
+     * is the phone's stacked column, picked by width in
+     * `PHONE_COLUMN_IDS`, and `tracklist.AllColumnIDs` in Go does not
+     * list it — so a tick in the configurator sends a column set the
+     * backend rejects with `unknown track-list column ID`, the tick
+     * reverts on the next render, and the only trace is a
+     * `console.error` (#197).
+     */
+    configurable?: boolean;
     /** Extracts the display value from a track. */
     accessor: (track: library.Track) => string;
     /** Default CSS width (used when no saved width exists). */
@@ -98,11 +110,16 @@ export const COLUMN_DEFS: Record<string, ColumnDef> = {
     },
     titleArtist: {
         id: 'titleArtist',
-        // Named for what it sorts by, since that is the only place the
-        // label is user-visible: the phone has no column headers, and
-        // the page header's sort list is built from the *configured*
-        // columns rather than the drawn ones.
+        // Named for what it sorts by. That label is drawn nowhere
+        // today: the phone has no column headers, and the page header's
+        // sort list is built from the *configured* columns, which this
+        // one can never be — see `configurable` below.
         label: 'Track Name',
+        // Chosen by width, never by the user, and rejected by the
+        // backend if it ever were. #197: Settings listed it anyway, so
+        // there were two rows called "Track Name" and the second one
+        // could not be selected.
+        configurable: false,
         accessor: (t) => t.TrackName,
         defaultWidth: '1fr',
         comparator: (a, b) => compareStr(a.TrackName, b.TrackName),
@@ -266,10 +283,15 @@ export const COLUMN_DEFS: Record<string, ColumnDef> = {
 };
 
 /**
- * All column IDs in default display order.
- * Used by the settings UI to list available columns.
+ * The column IDs Settings may offer, in default display order.
+ *
+ * Not every definition is one: a column the user cannot choose has no
+ * row in the configurator, because a checkbox that cannot change
+ * anything is worse than an absent one — see `ColumnDef.configurable`.
  */
-export const ALL_COLUMN_IDS: string[] = Object.keys(COLUMN_DEFS);
+export const CONFIGURABLE_COLUMN_IDS: string[] = Object.keys(
+    COLUMN_DEFS,
+).filter((id) => COLUMN_DEFS[id]?.configurable !== false);
 
 /**
  * Column IDs that are always searched regardless of visibility.

frontend/src/styles/sheet-scroll.css.ts

@@ -0,0 +1,68 @@
+import { css } from 'lit';
+
+/**
+ * A bottom sheet whose body scrolls says so, in one rule both sheets
+ * read.
+ *
+ * The app has two sheets — `menu-surface`'s context menu (#60) and
+ * `bottom-nav`'s "More" navigation (#71) — and both are capped at 85vh,
+ * because a surface covering the whole screen is a page rather than a
+ * sheet. So both overflow, and both used to overflow *silently*: the
+ * menu at 424x439 with eight items ending at y=470 (#207), the nav
+ * sheet at the same viewport with `scrollHeight` 412 against
+ * `clientHeight` 373 (#210). Where the cut lands on a row boundary the
+ * sheet ends in a clean edge that reads as the end of the list.
+ *
+ * The mechanism is #207's and is unchanged by being shared: two
+ * background layers on the scrolling box, whose *attachments* are the
+ * conditionality. A cover of the sheet's own colour is painted at the
+ * end of the *content* (`local`) over a shadow pinned to the box
+ * (`scroll`), so the cover scrolls up over the shadow exactly when
+ * there is nothing more to see. The fade is therefore absent on a sheet
+ * that fits, present the moment one does not, and gone again at the end
+ * of the list — with no scroll listener, no measurement and nothing
+ * reaching into another component's shadow root for the scroller.
+ * `background-attachment` is Chrome 4; the reference device is
+ * Chrome 113.
+ *
+ * Three things about it are load-bearing.
+ *
+ * **The cover takes the sheet's own colour, from a custom property.**
+ * The two sheets are different greys — the nav sheet paints
+ * `--yj-bg-surface`, because it holds the sidebar and two greys in one
+ * sheet is a seam across the middle of it, while the context sheet
+ * paints the menus' `--yj-bg-elevated`. A shared rule that hard-coded
+ * either would put that seam back on the other one, so the host sets
+ * `--yj-sheet-surface` on the same box and this reads it.
+ *
+ * **The curve is steep because the rows under it stay live.** A scrim
+ * over a menu item is that item's text surface, and this app's rule is
+ * that text clears 4.5:1 on every surface it can sit on — which the
+ * light ramp, whose `bgElevated` is `#e9ecef`, makes non-theoretical. A
+ * row is 48px with its label centred, so 32px of scrim already down to
+ * a quarter strength at 14px spends its weight on the strip below the
+ * last legible label: measured at 9.9:1 on that label on the light ramp,
+ * against 5.0:1 for a linear 48px draft at 0.8. The dark-ramp pixel
+ * table is in `.planning/NOTES.md` (2026-08-23).
+ *
+ * **The box is declared a scroller here too.** `overflow-y: auto` is
+ * part of the same statement rather than left to each host: a fade over
+ * a box that is not the scroller is a fade that never moves, and the
+ * component tier asserts the pair together for that reason.
+ */
+export const sheetScrollFade = css`
+    overflow-y: auto;
+    background:
+        linear-gradient(
+                var(--yj-sheet-surface, #343a40),
+                var(--yj-sheet-surface, #343a40)
+            )
+            bottom / 100% 32px no-repeat local,
+        linear-gradient(
+                to top,
+                rgba(0, 0, 0, 0.6) 0%,
+                rgba(0, 0, 0, 0.25) 45%,
+                rgba(0, 0, 0, 0) 100%
+            )
+            bottom / 100% 32px no-repeat scroll;
+`;

frontend/test/components/bottom-nav.test.ts

@@ -243,6 +243,62 @@ describe('bottom-nav', () => {
     expect(getComputedStyle(body).overscrollBehaviorY).toBe('contain');
   });
 
+  it('says where the fold is, in the sheet\'s own colour', async () => {
+    const el = await fixture<Nav>('bottom-nav');
+    const drawer = shadow<HTMLElement & { open: boolean }>(el, 'wa-drawer');
+
+    if (!drawer) throw new Error('no drawer');
+
+    const shown = once(drawer, 'wa-after-show');
+
+    shadow<HTMLButtonElement>(el, '[data-testid="tab-more"]')?.click();
+    await shown;
+
+    const body = drawer.shadowRoot?.querySelector('[part~="body"]');
+
+    if (!body) throw new Error('no body part to scroll');
+
+    const style = getComputedStyle(body);
+
+    // #210. This list does not fit the phone — measured at 424x439,
+    // `scrollHeight` 412 against `clientHeight` 373 with the seed's
+    // eight destinations — and said nothing about it, which where the
+    // cut lands on a row boundary reads as the end of the list.
+    //
+    // The mechanism is #207's and is asserted the same way: the pair of
+    // attachments *is* the feature. A cover of the sheet's own colour
+    // painted at the end of the content (`local`) over a shadow pinned
+    // to the box (`scroll`), so the fade is absent on a sheet that
+    // fits, present the moment one does not, and gone again at the end.
+    expect(
+      style.backgroundAttachment,
+      'the cover must be local and the shadow must not',
+    ).toBe('local, scroll');
+    expect(style.backgroundPosition).toBe('50% 100%, 50% 100%');
+    expect(style.backgroundSize).toBe('100% 32px, 100% 32px');
+
+    // And the colour is the local half of a shared rule: this sheet
+    // paints the sidebar's `--yj-bg-surface` (#212529) rather than the
+    // menus' elevated grey, or the fade draws the *other* sheet's
+    // colour across the bottom of this one — which is the seam a
+    // shared fragment would otherwise reintroduce.
+    expect(style.backgroundImage).toMatch(
+      /^linear-gradient\(rgb\(33, 37, 41\), rgb\(33, 37, 41\)\)/,
+    );
+
+    // And nothing paints over it. The sidebar's host carries the same
+    // grey, which inside the sheet is a second opaque copy of the
+    // surface drawn on top of these layers -- measured at 424x439 with
+    // the rule removed, the last 32px read a flat 52,58,64 with 39px
+    // still below, so the fade was painted and covered. That is
+    // `.context-menu-panel[data-sheet]`'s transparency, one sheet over.
+    const sidebar = shadow<HTMLElement>(el, 'app-sidebar');
+
+    if (!sidebar) throw new Error('no sidebar');
+
+    expect(getComputedStyle(sidebar).backgroundColor).toBe('rgba(0, 0, 0, 0)');
+  });
+
   it('gives the sheet the whole width, which the sidebar does not take', async () => {
     const el = await fixture<Nav>('bottom-nav');
 

frontend/test/components/menu-surface.test.ts

@@ -254,6 +254,15 @@ describe('menu-surface', () => {
       // Both sit at the bottom, or the cover hides nothing.
       expect(style.backgroundPosition).toBe('50% 100%, 50% 100%');
       expect(style.backgroundSize).toBe('100% 32px, 100% 32px');
+
+      // The layers are shared with `bottom-nav`'s sheet since #210, and
+      // the colour is what each host still says for itself: this one
+      // paints the menus' `--yj-bg-elevated` (#343a40). A shared rule
+      // that hard-coded one grey would draw a seam across the other
+      // sheet, which is why the fragment reads a custom property.
+      expect(style.backgroundImage).toMatch(
+        /^linear-gradient\(rgb\(52, 58, 64\), rgb\(52, 58, 64\)\)/,
+      );
     });
 
     /**

frontend/test/components/settings-column-list.test.ts

@@ -0,0 +1,190 @@
+/**
+ * Settings offers the columns the backend will accept, and no others.
+ *
+ * The list is built from `COLUMN_DEFS`, which is the *drawing* table:
+ * every definition the track list knows how to render, including
+ * `titleArtist` — the phone's stacked column, chosen by width in
+ * `PHONE_COLUMN_IDS` and never by a person. `tracklist.AllColumnIDs` in
+ * Go does not list that id, so the configurator offered a nineteenth
+ * row that could not be ticked:
+ *
+ * ```
+ * validate = unknown track-list column ID: "titleArtist"
+ * titleArtist valid = false
+ * ```
+ *
+ * What a user saw was **two rows both called "Track Name"** (#197), one
+ * of which did nothing — and a screen reader heard "Show the Track Name
+ * column" twice with nothing to tell them apart, which is `a11y.32`'s
+ * complaint inside the list that was fixed for exactly that.
+ *
+ * It is worse than an inert control, which is why the duplicate name
+ * was not the thing to fix. `SetTrackListColumns` assigns before it
+ * validates, so a rejected list stays in memory and `Save()` validates
+ * the whole config:
+ *
+ * ```
+ * later, unrelated SetThemeAccentColor = could not save config: invalid
+ *   config: ... unknown track-list column ID: "titleArtist"
+ * ```
+ *
+ * — one tick and no setting saves for the rest of the session. That
+ * half is filed separately; this file keeps the row from being offered.
+ *
+ * The last test is the one that would have caught it when the column
+ * was added: the two lists are in different languages, so nothing but a
+ * sweep can hold them together.
+ */
+import { beforeEach, describe, expect, it } from 'vitest';
+
+import '@components/config-page/config-page';
+
+import {
+  COLUMN_DEFS,
+  CONFIGURABLE_COLUMN_IDS,
+} from '@components/track-list/columns';
+import { flush, stub } from '@test/support/harness';
+import { fixture, shadowAll } from '@test/support/render';
+
+/** Go's own list of column ids, as text. */
+const GO_CONFIG = Object.values(
+  import.meta.glob<string>('../../../backend/tracklist/config.go', {
+    eager: true,
+    query: '?raw',
+    import: 'default',
+  }),
+)[0];
+
+/**
+ * The ids `tracklist.AllColumnIDs` actually contains.
+ *
+ * Read out of the source rather than written down here, because a
+ * third copy of this list is a third thing to forget — which is the
+ * defect, one copy earlier.
+ */
+function goColumnIDs(source: string): string[] {
+  const constants = new Map<string, string>();
+  const constBlock = /const \(([\s\S]*?)\n\)/.exec(source)?.[1] ?? '';
+
+  for (const [, name, id] of constBlock.matchAll(
+    /(\w+)\s+ColumnID\s*=\s*"([^"]+)"/g,
+  )) {
+    constants.set(name!, id!);
+  }
+
+  const listBlock =
+    /var AllColumnIDs = \[\]ColumnID\{([\s\S]*?)\n\}/.exec(source)?.[1] ?? '';
+
+  return [...listBlock.matchAll(/(\w+),/g)]
+    .map(([, name]) => constants.get(name!))
+    .filter((id): id is string => id !== undefined);
+}
+
+/**
+ * The column rows, and only those.
+ *
+ * Settings’ view-visibility list (#25) is drawn with the same two
+ * classes, so a bare `.column-label` sweeps 29 rows across two
+ * sections — and "Albums" the destination sitting beside "Album" the
+ * column is not the fault this file is about. The `for`/`id` prefix is
+ * what tells them apart.
+ */
+const COLUMN_ROW_LABEL = 'label.column-label[for^="column-"]';
+const COLUMN_ROW_BOX = 'input.column-toggle[id^="column-"]';
+
+/** The rows the configurator draws, by their visible name. */
+async function columnRowNames(): Promise<string[]> {
+  const page = await fixture('config-page');
+
+  await flush();
+  await page.updateComplete;
+
+  // Every section renders collapsed, and a collapsed body is `hidden`.
+  for (const section of shadowAll<HTMLElement>(page, 'config-section')) {
+    section.shadowRoot
+      ?.querySelector<HTMLButtonElement>('button[aria-expanded="false"]')
+      ?.click();
+  }
+
+  await flush();
+  await page.updateComplete;
+
+  return shadowAll<HTMLElement>(page, COLUMN_ROW_LABEL).map(
+    (label) => label.textContent?.trim() ?? '',
+  );
+}
+
+describe('the Settings column list', () => {
+  beforeEach(() => {
+    for (const path of [
+      'library.Library.GetAllLibrariesWithTrackCounts',
+      'jobs.Service.GetJobs',
+      'download.Service.ListProviders',
+      'download.Service.ProviderKinds',
+    ]) {
+      stub(path, []);
+    }
+
+    stub('config.Config.GetShortcuts', {});
+    stub('config.Config.GetDownloadPreferences', {});
+    stub('config.Config.GetThemeAccentColor', '#ffd43b');
+    stub('config.Config.GetThemeBackgroundShade', 'dark');
+  });
+
+  it('names each row once', async () => {
+    const names = await columnRowNames();
+
+    // A sweep over nothing passes.
+    expect(names.length, 'the page draws column rows').toBeGreaterThan(5);
+
+    const seen = new Set<string>();
+    const duplicated = names.filter((name) => !seen.add(name));
+
+    expect(duplicated).toEqual([]);
+    expect(names.filter((n) => n === 'Track Name')).toHaveLength(1);
+  });
+
+  it('gives each checkbox a name that identifies it', async () => {
+    // The visible half above is what was reported; this is the half a
+    // screen reader gets, and it is the one `config-page` computes
+    // from the same string.
+    const page = await fixture('config-page');
+
+    await flush();
+    await page.updateComplete;
+
+    const labels = shadowAll<HTMLInputElement>(page, COLUMN_ROW_BOX).map(
+      (box) => box.getAttribute('aria-label') ?? '',
+    );
+
+    expect(labels.length, 'the page draws column checkboxes').toBeGreaterThan(5);
+    expect(new Set(labels).size).toBe(labels.length);
+  });
+});
+
+describe('the column table', () => {
+  it('offers no column the backend would reject', async () => {
+    const accepted = goColumnIDs(GO_CONFIG ?? '');
+
+    // Two non-vacuity guards: a glob that stopped matching, and a
+    // parse that stopped finding the list it names.
+    expect(GO_CONFIG, 'backend/tracklist/config.go is readable').toBeTruthy();
+    expect(accepted.length, 'AllColumnIDs was parsed').toBeGreaterThan(10);
+
+    expect(
+      CONFIGURABLE_COLUMN_IDS.filter((id) => !accepted.includes(id)),
+    ).toEqual([]);
+  });
+
+  it('still knows how to draw every column it offers', async () => {
+    // The filter must not have taken a column *out* of the drawing
+    // table: `configurable` says what Settings may list, not what the
+    // list may render.
+    expect(
+      CONFIGURABLE_COLUMN_IDS.filter((id) => COLUMN_DEFS[id] === undefined),
+    ).toEqual([]);
+    expect(CONFIGURABLE_COLUMN_IDS).not.toContain('titleArtist');
+    expect(COLUMN_DEFS['titleArtist'], 'the phone still has its column')
+      .toBeTruthy();
+  });
+});