feat: [TESIS-999012] filter the catalog by category

[LauAubert]

Ticket de Jira

https://proyectofinalfrlp.atlassian.net/browse/TESIS-999012

ID provisorio: se reemplaza por la clave real al cargar la card en Jira. Card: cards/012.md.

---

Descripción

La API filtra el catálogo por categoría (GET /products?category=, Product.by_category) y GET /products/categories existe, según su propio comentario, «para que el modal de alta y el filtro del listado no repitan la lista». Pero el catálogo (S10) no tenía filtro por categoría. Este PR agrega el select junto al buscador.

PR apilado sobre proyecto-web#66 (card 011): usa useCategories y el vocabulario que agrega esa rama. Se mergea después de #66.

Decisiones que conviene mirar:

En la URL, como la pestaña. ?category=Power se puede enlazar y sobrevive a un F5, con el mismo replace que la pestaña (cambiar de filtro no deja una entrada por opción en el historial). Elegir una categoría vuelve a la página 1.

Los contadores cuentan dentro de la categoría. Si no, la pestaña diría «Todos (1.284)» con la tabla filtrada a tres filas. useProductCounts, fetchProductCount y la clave inventoryKeys.count suman la categoría.

Un filtro aplicado siempre se ve. La categoría de la URL no se valida contra el vocabulario —la lista llega después del primer render, y una categoría inexistente devuelve cero filas, que es la respuesta honesta—, pero se ofrece en el select aunque la lista no la traiga. La regla vive en utils/categories.ts (categoryOptions) y la comparte con el CategoryField de los modales.

• Agrega el select «Categoría» a InventoryPage, con el parámetro category en la URL.
• fetchProductCount, useProductCounts e inventoryKeys.count aceptan la categoría.
• Agrega utils/categories.ts y lo usa también en CategoryField.
• Tests: la página (sin filtro, filtro desde la URL, elegir, contadores, volver a todas) y el util.

---

Evidencia visual

Pendiente de captura con la API levantada.

---

Cómo probar

Precondición: API de master, bin/rails db:seed, login con un usuario de Norte.

1. Inventario → el select «Categoría» dice «Todas las categorías».
2. Elegir «Electronics» → la tabla y los contadores de las pestañas muestran sólo esos productos; la URL suma ?category=Electronics.
3. Recargar → sigue filtrado. Combinar con la pestaña «Stock bajo» → los dos filtros aplican.
4. Volver a «Todas las categorías» → el parámetro desaparece.

Verificación: npm run test (693 tests, 0 fallas), npm run lint, npm run format:check y npm run build limpios.

---

Impacto y consideraciones

¿Introduce breaking changes?
No

¿Requiere nuevas variables de entorno?
No

¿Afecta la arquitectura o genera un nuevo patrón?
No. Mismo patrón que la pestaña en la URL (TESIS-55).

🤖 Generated with Claude Code

[TomasMartin2004]

Revisado. No lo mergearía para esta entrega.

No tengo nada en contra: el filtro aprovecha GET /products?category= y GET /products/categories, que ya existen, y es consistente con el buscador que ya está al lado.

Pero es funcionalidad nueva sobre el catálogo, no la corrección de nada: hoy el catálogo se busca por texto y anda. La que sí mergearía de este par es #66, porque ahí hay un cartel que miente en pantalla («Pendiente de backend: el producto todavía no tiene categoría») cuando el backend lo soporta hace rato. Este es el paso siguiente, y el paso siguiente puede esperar.

Ojo con una cosa: está apilado sobre la rama de #66. Si #66 entra y este no, conviene desapilarlo para que no quede una rama abierta colgando de una que ya se mergeó.