fix(ui): keep a touch-only affordance reachable, or absent

Three controls are revealed by :hover and are the only route to their
action on a device that has none. #68 hid the home card's play button on
touch, which was right because tapping the card does the same thing;
these are the opposite case, so hiding them removes the action outright
and leaving them costs the same long-press flash #68 was filed for --
they are visibility:hidden / opacity:0, so on touch they are invisible
controls that still take taps.

track-details' cover-art overlay and remove, and shortcut-capture's
reset, are always visible under `@media not all and (hover: hover)`.

The queue row's remove is the third case the report names and takes the
other treatment, because #60 has since landed: the row's context menu is
a bottom sheet carrying "Remove from Queue", so the action is one
long-press away and an always-visible X would spend part of a 424px row
on something already reachable. It is display:none outside
`(hover: hover) and (pointer: fine)` rather than visibility:hidden,
which would leave a button holding its hit area and its place in the
accessibility tree -- the trap this issue is about.

The rule is not extracted into styles/ yet: that leaves two call sites
of the always-visible form, under the four the report names.

No tier here can render as a touch device, so the tests read the parsed
stylesheet the way #68's does and say so; the touch and hover renderings
were measured against the running app in a hasTouch context instead.

Closes #137

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

@@ -79,6 +79,17 @@ export class ShortcutCapture extends LitElement {
         .reset-btn:hover {
             color: var(--yj-accent-text, #ffd43b);
         }
+        /*
+         * Reset is the only way to put a rebound shortcut back, so where
+         * the device has no hover it is always visible rather than an
+         * invisible button holding its hit area. The inverse of #68's
+         * rule, which applies where the hover control is redundant.
+         */
+        @media not all and (hover: hover) {
+            .reset-btn {
+                opacity: 1;
+            }
+        }
     `;
 
     private handleClick = () => {

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

@@ -639,23 +639,42 @@ export class QueuePanel
             text-overflow: ellipsis;
         }
 
+        /*
+         * The per-row remove is a hover affordance, and on a device
+         * without hover it is redundant rather than missing: the row's
+         * context menu is a bottom sheet since #60 and carries "Remove
+         * from Queue", so the action is one long-press away. An
+         * always-visible X would instead spend part of a 424px row on
+         * something already reachable. #68's treatment, for #68's reason.
+         *
+         * display:none outside the query rather than visibility:hidden:
+         * a hidden button still occupies its hit area and is still in
+         * the accessibility tree, so a phone would keep a target for a
+         * control it can never see.
+         */
         .remove-button {
-            background: none;
-            border: none;
-            color: var(--yj-text-tertiary, #888);
-            cursor: pointer;
-            padding: 4px;
-            display: flex;
-            align-items: center;
-            visibility: hidden;
+            display: none;
         }
 
-        .track-item:hover .remove-button {
-            visibility: visible;
-        }
+        @media (hover: hover) and (pointer: fine) {
+            .remove-button {
+                background: none;
+                border: none;
+                color: var(--yj-text-tertiary, #888);
+                cursor: pointer;
+                padding: 4px;
+                display: flex;
+                align-items: center;
+                visibility: hidden;
+            }
 
-        .remove-button:hover {
-            color: var(--yj-error-text, #ff8787);
+            .track-item:hover .remove-button {
+                visibility: visible;
+            }
+
+            .remove-button:hover {
+                color: var(--yj-error-text, #ff8787);
+            }
         }
 
         .list-area.drag-over {

frontend/src/components/track-details/track-details.ts

@@ -529,6 +529,21 @@ export class TrackDetails extends LitElement {
             background: var(--yj-error, #e03131);
         }
 
+        /*
+         * Both are the *only* route to changing or removing a track's
+         * cover art, so where the device has no hover they are always
+         * visible rather than hidden — the inverse of #68's rule, which
+         * applies where the hover control is redundant. Revealed by
+         * opacity, so what is on screen is what the desktop reveal shows
+         * and nothing about the layout moves.
+         */
+        @media not all and (hover: hover) {
+            .cover-art-overlay,
+            .cover-art-remove {
+                opacity: 1;
+            }
+        }
+
         /* Error message */
         .error-message {
             flex: 1;