feat(ui): the track list a phone can read

B2 phase 4, and the last of it. Measured on the device: at 424 CSS px
the four configured columns fit the row *exactly* -- `--grid-cols` came
out `24px 102px 101px 101px 80px` -- and not one of them fit its
content, with "Duration" too narrow for its own header. The columns were
never too wide; there were too many of them.

So a phone draws `titleArtist` (the title with the artist under it,
across the row's whole width) plus the duration, and drops the column
headers and the resize handles, which are a click-to-sort and a drag
with no touch equivalent. It is a **column set, not a second row
template**: the row, its delegated events, the selection semantics, the
playing marker and the virtualizer never learn anything changed, because
from their side only the number of columns did.

Three rules come with it. The row height is in two places
(`PHONE_ROW_HEIGHT` and the CSS rule) and must agree, since the
virtualizer positions rows from that number and a taller row overlaps
its neighbour. What is drawn and what can be sorted are different
questions, so the sort list is built from `configuredColumns` -- a phone
has no headers either, and building it from the drawn columns would
leave it able to sort by title and duration alone. And a phone's column
widths are neither loaded nor saved.

That third rule is the bug the device found with the arrangement already
passing five component tests and five e2e specs at the phone's own
viewport. `loadColumnWidths` is keyed by column *id* and fills a gap
with `MIN_COLUMN_WIDTH`, so the stacked column -- which nothing can ever
have saved a width for -- came out at 148px beside a duration column of
236. The mirror image was worse and unreachable from a phone at all:
saving would have written those widths back under the same ids,
replacing the width the user dragged on a desktop. The specs asserted
shape, and the fault depended on what `localStorage` held for a
different column set; the unit test now carries that map as a fixture.

Verified: 809 component tests, 112 e2e specs, and on the phone at
424x439 -- `24px 304px 80px`, 52px rows, no truncation, no overflow.
One full e2e run of three saw an unrelated autotag keypress spec flake
and pass on retry.

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

@@ -9,6 +9,8 @@ import {
 import { formatMilliseconds } from '@utils/time';
 import { html, nothing } from 'lit';
 
+import { highlightText } from './search-ranking';
+
 /** Compares two strings using locale-aware ordering. */
 const compareStr = (
     a: string,
@@ -36,8 +38,17 @@ export interface ColumnDef {
     defaultWidth: string;
     /** Text alignment. Defaults to left. */
     align?: 'left' | 'right';
-    /** Optional custom render function returning an HTML template. */
-    renderCell?: (track: library.Track) => unknown;
+    /**
+     * Optional custom render function returning an HTML template.
+     *
+     * `term` is the active search term, for a cell that wants to
+     * highlight its own text: the default path applies `highlightText`
+     * to `accessor`'s value, and a cell that renders itself has to do
+     * that itself or silently lose the highlight. Only `titleArtist`
+     * needs it, which is why it is optional rather than a second
+     * required parameter on all of them.
+     */
+    renderCell?: (track: library.Track, term?: string) => unknown;
     /**
      * Comparison function for sorting two tracks by this column.
      * Returns negative if a < b, positive if a > b, zero if equal.
@@ -85,6 +96,27 @@ 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.
+        label: 'Track Name',
+        accessor: (t) => t.TrackName,
+        defaultWidth: '1fr',
+        comparator: (a, b) => compareStr(a.TrackName, b.TrackName),
+        renderCell: (t, term) => html`
+            <div class="stacked">
+                <span class="stacked-title"
+                    >${term ? highlightText(t.TrackName, term) : t.TrackName}</span
+                >
+                <span class="stacked-sub"
+                    >${term ? highlightText(t.ArtistName, term) : t.ArtistName}</span
+                >
+            </div>
+        `,
+    },
     trackName: {
         id: 'trackName',
         label: 'Track Name',
@@ -249,6 +281,24 @@ export const CORE_SEARCH_COLUMN_IDS: string[] = [
     'album',
 ];
 
+/**
+ * The one column a phone shows, and it is two lines.
+ *
+ * At 424 CSS px -- the width of the phone this was measured on -- four
+ * columns fit the row exactly and none of them fits its *content*:
+ * `--grid-cols` came out `24px 102px 101px 101px 80px`, so "Duration"
+ * did not fit its own header and a title had ~20 characters. The
+ * columns were never too wide; there were too many of them.
+ *
+ * So the phone gets the title with the artist under it, which is the
+ * shape every phone music list has, and the full row width to put them
+ * in. It is a *column definition* rather than a second row template on
+ * purpose: the row, the delegated events, the selection semantics, the
+ * playing marker and the virtualizer all keep working, because from
+ * their side nothing has changed except how many columns there are.
+ */
+export const PHONE_COLUMN_IDS: string[] = ['titleArtist', 'trackLength'];
+
 /**
  * Default column IDs. Album is in them (H-15): without it, the three
  * `Tideline / Aurora Fields / 00:06` rows in this app's own fixture