feat(player): give the transport a context, and thumb-sized controls

Measured at the reference device's 424x439, every button here was
33x21px -- in the bottom bar and on the full-screen view alike. #56
reports them as "the most important thing in the mobile app and they
are tiny", and that is the number behind it.

The context is a **property, not a media query**, and that is the whole
design. Everywhere else in this app a component states what it drops at
phone width itself, because a media query inside a shadow root is
answered by the viewport and that is the honest signal. Here the two
hosts want different answers at the *same* viewport: on a phone the bar
wants three controls sized for a thumb and now-playing-view wants five,
larger still. So the host says which context and the viewport says
which size band, and neither alone can express it.

Play/pause alone goes above the 44px floor. A row of five identical
squares says every action is equally likely, which is not true of play
-- "large play/pause, adequate prev/next" is the Direction, and a spec
caught that the first version had sized all three the same.

Two things that fail silently:

The desktop bar must not move, and a `<button>` does not inherit its
font from its parent -- the UA stylesheet gives it one. So a generic
`font-size: inherit` is not the no-op it reads as: it took every
desktop control from 33x21 to 36x24. The box rules take a zero fallback
and the font-size rules are scoped to the two contexts that set one.

And the art on now-playing-view overflowed its own box, drawing over
the header above and the title below, because `aspect-ratio: 1` with a
definite width derives a height that nothing bounds -- 60vh bounds the
viewport, not the room left over. `max-height: 100%`. Pre-existing;
found by reading a screenshot, which is the only tier that can see it.

What is left is #172: with the transport at 172px of a 439px screen the
art is a 39px sliver.

Closes #56

frontend/src/components/now-playing-view/now-playing-view.ts

@@ -117,8 +117,27 @@ export class NowPlayingView extends LitElement {
         .art .placeholder {
             /* Square, and never taller than the room left over: the
                art is the one thing here that would happily push the
-               transport off the bottom of a short phone. */
+               transport off the bottom of a short phone.
+
+               **max-height is what actually keeps that promise**, and
+               it was missing. With a definite width and
+               a 1:1 aspect-ratio the height is *derived from the width*
+               and is bounded by nothing: at the reference device's
+               424x439 that is a 263px square (60vh) in a box with far
+               less than 263px left, so the art overflowed its own
+               centred flex item and drew over the header above and the
+               title below it. The comment claimed this was handled;
+               60vh is a bound on the *viewport*, not on the room left
+               over, and those differ by however much chrome is above
+               and below.
+
+               Pre-existing -- screenshotted on main -- and made acute
+               by #56, which gives the transport 95px more than it had.
+               Found by reading a screenshot, which is the only tier
+               that can see it: nothing fails, nothing overflows the
+               *shell*, and every control is still hittable. */
             width: min(100%, 60vh);
+            max-height: 100%;
             aspect-ratio: 1;
             object-fit: cover;
             border-radius: 12px;
@@ -317,7 +336,13 @@ export class NowPlayingView extends LitElement {
 
             <div class="transport">
                 <seek-bar></seek-bar>
-                <player-controls></player-controls>
+                <!-- context="full": this view *is* the player, so the
+                     transport is the page rather than a strip of it --
+                     primary controls large, shuffle and repeat beneath
+                     at normal size (#56). It is a property rather than
+                     a media query because the bottom bar wants a
+                     different answer at this same viewport. -->
+                <player-controls context="full"></player-controls>
                 <volume-control></volume-control>
             </div>
         `;