feat: catálogo como centro del embudo y captura de baja fricción

Reestructuración pedida por el cliente tras revisar la primera versión.

Conversión:
- Formulario de 14 campos a 4: nombre, correo, teléfono y mensaje. La
  clasificación de riesgo ya no se pregunta, se deduce del contexto de la
  página y viaja oculta. Menos fricción, misma riqueza para el análisis.
- El inicio deja de bifurcar y empuja al catálogo: 36 llamados desembocan
  ahí, y las rutas por industria y escenario pasan a ser la forma de entrar
  al catálogo ya filtrado, en lugar de competir como destino.
- Catálogo rehecho como tienda: barra lateral con filtros, búsqueda que
  acepta expresiones regulares, títulos que abren la ficha, un solo botón
  primario por tarjeta y el comparador detrás de un desplegable.
- Ficha de producto orientada al cierre: bloque en lenguaje llano sobre si
  el equipo corresponde al caso, y "Cotizar este equipo" con el formulario
  precargado. Se retiraron los enlaces que sacaban del embudo a leer normas.
- Todos los llamados se unifican en "Recibir cotización".
- Widget de WhatsApp: nombre, teléfono, correo y mensaje libre. El texto que
  escribe la persona es el que viaja a la conversación.

Doble audiencia:
- 13 escenarios con la iconografía original de FSPM traducen un lugar
  reconocible a clases de fuego y productos, para quien no domina la
  terminología. La capa técnica se conserva para búsqueda.
- Héroe con fotografía en todas las landings.

Correcciones:
- El contenedor moría al arrancar porque el CLI de Prisma no podía escribir
  sus motores; el chown ahora incluye /app/prisma-cli.
- Iconos repetidos entre escenarios. El set original no tiene icono de
  cocina, así que ese escenario usa un marcador tipográfico explícito.
- FIREMIKS no aparecía en ningún escenario.
- Los ids de campo del formulario colisionaban con dos instancias por página.
- Se documentó el despliegue, que faltaba por completo.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

tests/02-responsivo.spec.ts

@@ -11,6 +11,16 @@ import { ANCHOS, RUTAS_MUESTRA } from "./rutas";
  * página desplazándose en horizontal no lo está nunca.
  */
 
+/**
+ * El barrido de anchos corre en Chromium y en WebKit de escritorio, no en los
+ * cuatro proyectos. El desborde horizontal lo produce el CSS, no el motor, así
+ * que repetir 5 anchos × 10 rutas en cuatro navegadores multiplicaba el tiempo
+ * de la suite sin agregar información. WebKit sigue incluido porque es donde
+ * aparecen las diferencias reales de `dvh`, `env()` y flexbox, y los proyectos
+ * móviles conservan las pruebas de interacción de más abajo.
+ */
+test.describe.configure({ mode: "parallel" });
+
 async function desbordaEnHorizontal(page: Page): Promise<{ desborda: boolean; ancho: number; visible: number }> {
   return page.evaluate(() => {
     const doc = document.documentElement;
@@ -55,7 +65,12 @@ async function culpablesDeDesborde(page: Page): Promise<string[]> {
 }
 
 for (const ruta of RUTAS_MUESTRA) {
-  test(`sin desborde horizontal en ${ruta}`, async ({ page }) => {
+  test(`sin desborde horizontal en ${ruta}`, async ({ page }, info) => {
+    test.skip(
+      !["escritorio-chromium", "escritorio-webkit"].includes(info.project.name),
+      "El barrido de anchos corre solo en los dos proyectos de escritorio; ver la nota de arriba.",
+    );
+
     await page.goto(ruta, { waitUntil: "networkidle" });
 
     for (const ancho of ANCHOS) {