F-100 — Arquitectura: generación automática de SKU a partir del título

Estado actual

En POST /products (catálogo) se crea una variante por defecto con sku = "SKU-MV-${productId}".
El admin no expone la edición del SKU en PriceStockSection (sólo EAN, precios, stock).
No hay endpoint de "sugerir SKU" en el backend.

Helper puro src/modules/catalog/domain/sku.ts:
- generateSkuFromTitle(title): normaliza el título (mayúsculas, sin diacríticos, sin caracteres no alfanuméricos, guiones separadores, recorte a 100 chars). Devuelve MV-<SLUG>.
- uniqueSku(base, existing: Set<string>): si el base está ocupado, prueba base-2, base-3, … hasta encontrar uno libre.
Backend:
- Cambiar la creación de producto para usar el SKU derivado del título en lugar del UUID; mantener uniqueSku para resolver colisiones.
- Endpoint nuevo POST /admin/products/sku:generate con body { title: string } → { sku: string }. Útil para preview antes de crear.
- Permitir que el admin edite el SKU en la sección "Precios y Stock" (PriceStockSection). Persistencia vía PATCH /products/:id/variants/:variantId.
Admin UI (apps/admin):
- api-client.ts: productsApi.generateSku(title) y productsApi.updateVariant(id, vid, { sku }).
- Sección "Precios y Stock": muestra el SKU actual como input editable con botón "Regenerar" que llama al endpoint.
- Página de creación de producto: llama a generateSku al blur del nombre para previsualizar el SKU.
Validación:
- SKU: ^[A-Za-z0-9-]+$, 1..100 chars (alineado con newVariantSchema).
- El endpoint /admin/products/sku:generate sólo da sugerencias; el cliente decide.
- Duplicados: PostgreSQL ya rechaza por UNIQUE en product_variants.sku. Aclarar el error al admin con un mensaje claro.

sku.test.ts (6-8): normalización, acentos, longitudes, collision in uniqueSku.
Añadir test al repositorio Variantes (e2e) si el repo expone findBySku: comprobar que se devuelve un SKU existente para validar.