Etapa 1 (auditoria/propuesta, sin codigo) de la Etapa 3 de Fase 5: motor de busqueda y filtros facetados reales, reemplazando el filtrado/conteo 100% client-side que dejo la sub-fase 3 de Etapa 2. Verificado contra documentacion oficial vigente (no memoria de entrenamiento): - Medusa no tiene modulo de busqueda propio integrado con Meilisearch; el Search Module nativo llego en Medusa 2.19, y el plugin comunitario @rokmohar/medusa-plugin-meilisearch se conecta a el solo desde su version ^2.0.0 (requiere Medusa >=2.19). Nuestro backend corre Medusa 2.18.0 -- la version compatible es la linea ^1.4.1 del plugin (Medusa >=2.15 <2.19), documentada como deuda tecnica explicita si se sube Medusa mas adelante. - Impacto de recursos evaluado contra el estado real del host (swap al 100%, mismo tipo de contencion que el incidente de Gitea): Meilisearch recomendado sobre Typesense por menor huella de RAM y por ser el unico con integracion Medusa mantenida para nuestra version -- comparacion mantenida breve porque la diferencia es clara, sin profundizar mas de lo necesario. - Diseno de indexacion (campos buscables/filtrables/ordenables), sincronizacion (mismo patron de subscriber por eventos que revalidate-storefront.ts, sumando product-category.* al set de eventos) y UI de facetas/autocompletado (reutiliza catalog-client.tsx y CatalogProvider.searchProducts ya existentes, sin componentes nuevos). Cross-referencia agregada en ADR 0004 (que ya habia identificado Meilisearch como paso natural) y entrada nueva en mkdocs.yml. Etapa 2 (implementacion) NO arranca hasta aprobacion explicita de esta propuesta.