docs(sound-engine): bar solo colapsa bajo 800px, y la mezcla la elige el disenador

El barrido de anchos reencuadra el defecto: bar esta sano de 900px en adelante
(scrubber 147/347/1047) y solo colapsa a 720px, que es el ancho al que la demo
encierra al player, no un ancho propio de una barra de app persistente.

Corrige ademas la pregunta que yo habia planteado. El usuario zanjo que la
mezcla es composicion y la elige el disenador, lo que encaja con la doctrina que
audio-player.css ya declara (un variant decide que se muestra y como fluye,
nunca comportamiento) y con la salida que ya existe: componer MediaPlayer
media=audio a mano mantiene el flujo sin opinion, porque el CSS de variantes
cuelga de data-variant y eso solo lo estampa AudioPlayer.

Lo que no se disuelve en composicion es que el preset colapse EN SILENCIO. El
arreglo pendiente no arbitra entre scrubber y volumen: min-inline-size en el
scrubber para que nunca llegue a 0, y el ancho minimo documentado.

Y registra dos veredictos del usuario: waveform F6 APROBADA (cierra el pendiente
del 2026-08-01) y variante card APROBADA. Quedan row e inline.

docs:check 0 sobre 564 documentos.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/process/CONTINUE-sound-engine.md

@@ -200,15 +200,43 @@ programáticamente, buscando partes colapsadas, botones estrujados y desbordes:
   correcto (la receta lo esconde si no hay directo).
 - `inline`: oculta artwork/title/artist/time/rate/mute/volume — **por diseño**,
   es lo que la receta declara para la nota de voz.
-- **`bar`: el defecto.** `time-slider` colapsado a **ancho 0** y `mute-button` a
-  **20px**, en las **cuatro** combinaciones — así que no es del eje ni del tema,
-  es que la fila no tiene sitio. **Visto**: el scrubber queda reducido a un solo
-  punto ámbar entre `0:00` y `6:12`, o sea una barra de app persistente **sin
-  barra de progreso**, mientras el slider de **volumen** sí conserva su ancho
-  completo. Ningún desborde en ninguna combinación.
-
-Queda la **mirada** del usuario sobre `card`/`row`/`inline` (la medición no juzga
-estética) y la decisión de qué cede en `bar`.
+- **`bar`: colapsa, pero SÓLO por debajo de ~800px.** Barrido de anchos del
+  contenedor, con la variante verificada en la misma medida:
+
+  |  ancho | scrubber |   mute |
+  | -----: | -------: | -----: |
+  |  720px |    **0** | **20** |
+  |  900px |      147 |     36 |
+  | 1100px |      347 |     36 |
+  | 1800px |     1047 |     36 |
+
+  De 900px en adelante está **sano**. Los 720px son el ancho al que **la demo**
+  encierra al player, no un ancho propio de una barra de app persistente (la
+  referencia declarada es Spotify, que ocupa la ventana entera). **Visto a
+  720px**: el scrubber queda reducido a un punto ámbar entre `0:00` y `6:12`
+  mientras el volumen conserva sus 64px. Ningún desborde en ninguna combinación.
+
+### El diagnóstico correcto — corrección del usuario (2026-08-04)
+
+La pregunta que yo había planteado, **«¿qué cede en `bar`?», es la pregunta
+equivocada a nivel de framework**. El usuario lo zanjó: _«¿no es un diseño por
+composición? debe de ser por composición y eso lo elegirá el diseñador»_. Y
+encaja con la doctrina que el propio `audio-player.css` ya declara — un variant
+sólo decide **qué se muestra y cómo fluye**, nunca comportamiento — y con la
+salida que ya existe: componer `<MediaPlayer media='audio'>` a mano mantiene el
+flujo sin opinión, porque todo el CSS de variantes cuelga de `[data-variant]`,
+que **sólo estampa `<AudioPlayer>`**. Quien quiera otra mezcla a 720px, compone.
+
+Lo que NO se disuelve en composición: que un preset **colapse en silencio**. El
+diseñador no recibe ninguna señal de que está por debajo del ancho viable — el
+control simplemente desaparece. El arreglo, por tanto, **no arbitra** entre
+scrubber y volumen; sólo hace honesto el fallo. Pendiente de decisión del
+usuario, dos piezas que no eligen ganador:
+
+- un `min-inline-size` en el scrubber, para que nunca llegue a 0 (la fila
+  desborda o envuelve, visible, en vez de comerse el control), y
+- documentar en el README el ancho mínimo de `bar` (~900px), que es un valor de
+  diseño de la variante, como ya lo son los tamaños de carátula.
 
 ## Pendiente que solo puede hacer el usuario
 
@@ -228,15 +256,16 @@ escenario mixto y teclas de medios.
 
 De este hilo quedan **cuatro cosas, y ninguna es código a ciegas**:
 
-1. **La mirada del usuario sobre el modo audio** — `card` / `row` / `inline`.
-   La matriz está medida (sección F6) y sólo `bar` tiene defecto; el juicio
-   estético de las otras tres es suyo.
-2. **Qué cede en `bar`** — decisión de diseño, no se improvisa. Hoy el
-   `time-slider` colapsa a 0 y el mute a 20px mientras el volumen conserva su
-   ancho. Opciones obvias: dar `flex` al time-slider y quitárselo al volumen ·
-   esconder el volumen por debajo de cierto ancho · bajar el scrubber a una
-   segunda fila.
-3. **La mirada del waveform (su F6)** — sigue pendiente desde el 2026-08-01.
+1. ~~**La mirada del waveform (su F6)**~~ ✅ **APROBADA por el usuario
+   (2026-08-04): «waveform … las veo bien».** Cierra el pendiente que arrastraba
+   desde el 2026-08-01.
+2. **La mirada sobre el resto del modo audio** — ✅ `card` **aprobada** el
+   2026-08-04 («la variante card la veo bien»). Quedan **`row`** e **`inline`**;
+   la matriz dice que están sanas, pero la medición no juzga estética.
+3. **`bar` por debajo de su ancho** — el usuario ya fijó el criterio: la mezcla
+   es **composición y la elige el diseñador**, así que el framework NO arbitra.
+   Queda decidir sólo las dos piezas que hacen honesto el fallo (ver §F6):
+   `min-inline-size` en el scrubber + ancho mínimo documentado.
 4. **El rojo de `audio-player` en `lint.test.ts`** — guard compartido, decisión
    pendiente entre categoría nueva o `KNOWN_MISSING_MORFO`.