plan: record what the live queue and the log actually said

The measurements behind the second pass — 121 entries with 121 distinct
provider ids, 13 same-title groups all differing by tens of seconds, 3664
spectrum flaps ~1s apart, and one mislabelled shutdown error — plus the
one fix deliberately left out (the UI-thread unwraps).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

plan/summary.md

@@ -1977,3 +1977,47 @@ keys plus toolbar buttons driving the same menu, and the CLI `queue dedup` /
 `queue sort <key> [--desc]` with the strategy as a `ValueEnum` so a typo fails
 before a round trip. 556 workspace tests green, clippy clean, the wasm bundle
 and the book build.
+
+## Queue order, second pass: what a real queue and a real log said (2026-07-29)
+
+Four things, all found by measuring rather than reasoning.
+
+**Dedup by title (D3a).** Tried against a live 121-entry queue, the
+provider-item identity removed *nothing* — 121 entries, 121 distinct ids —
+while the queue plainly held three "Sink Into The Hips". Reading the entries
+settled it: distinct ISRC-style ids, 171/189/228 s, two from the remixes album
+and one from the album. Different recordings, which the default is right to
+keep. Across the queue, 13 same-title groups (19 droppable entries) and *every*
+group differed by tens of seconds, which also killed the duration-tolerant
+middle option: any tolerance narrow enough to be safe caught nothing. So the
+blunt identity ships as an opt-in flag with its own key (`U`,
+`queue dedup --titles`), lowercased (artist, title), survivor = the playing
+entry else the longest take.
+
+**The screen artefact was stderr.** `tracing` goes to a file because the TUI
+owns the screen — but fd 2 did not, and in the bundled `cbd` the ALSA C library
+shares the process. Its `underrun occurred` printed onto the interface, scrolled
+the terminal a line, and since ratatui repaints only changed cells the shift
+persisted: the queue looked like it had bled into the now-playing pane. The
+message never reached the log either, which is why the log had no underrun in
+it. One `dup2` before the alternate screen sends fd 2 to `cbd.stderr.log`, so
+the diagnostics are kept off-screen rather than lost.
+
+**A metronomic spectrum flap.** 3664 `audio idle` → `audio flowing` pairs in one
+day's log, ~1 s apart *during* playback. Not device starvation — the regularity
+was the tell. tokio's default `MissedTickBehavior::Burst` keeps the absolute
+schedule, so once the per-tick FFT lateness accumulates to one whole period, two
+ticks fire back to back and the second one necessarily sees no new frames; the
+zero-tolerance idle check read that as silence and zeroed the bars. `Delay` plus
+a two-tick `FlowDetector` fixes both the flicker and the log noise.
+
+**The log's only ERROR was a shutdown race.** "request to server failed: sending
+on a closed channel" was the orchestrator sending to the *UI* channel after the
+UI thread exited — a clean quit, reported as a server failure, followed by a
+loop spinning on a stream nobody was reading. It now reports the UI closing at
+info and returns.
+
+Not done, deliberately: the two `unwrap()`s on `event::poll`/`event::read` still
+panic the UI thread on a terminal read error, and that path leaves the terminal
+in raw mode. Left out of this pass by choice; it wants a panic hook that
+restores the terminal first.