fix: [TESIS-999029] refresh the stock per warehouse after a lack-of-stock 422

[LauAubert]

Ticket de Jira

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

ID provisorio: se reemplaza por la clave real al cargar la card en Jira. Card: cards/029.md. Sale de una auditoría de código del front (TESIS-89).

---

Descripción

El stock por depósito que muestran el alta manual (paso 2) y la modificación de órdenes queda cinco minutos en caché. Si otra venta o un webhook se llevan esas unidades, confirmar la orden o guardar la modificación responde 422 «Insufficient stock», pero nada refrescaba esa caché:

• useConfirmDraftOrder no invalidaba nada cuando la orden no había llegado a crearse.
• useUpdateOrder sólo invalidaba en onSuccess.

Resultado: el paso 2 seguía marcando el mismo depósito como «cubre todo», la edición no avisaba ningún faltante, y reintentar fallaba de la misma forma hasta que vencía la caché.

• useConfirmDraftOrder invalida ['inventory'] cuando la orden no se creó y el rechazo es un 422.
• useUpdateOrder suma un onError que invalida ['inventory'] con un 422.
• Cualquier otra falla (red, 500, 412) no toca la caché: no dice nada del stock.
• Tests de los dos hooks: el 422 invalida el stock por depósito; un 500 o un 412 no.

---

Evidencia visual

N/A

---

Cómo probar

1. Abrir el alta manual con un producto de 5 unidades en un depósito y llegar al paso 3.
2. En otra pestaña, vender esas unidades.
3. «Confirmar orden» → 422. Volver al paso 2 → el depósito ya no aparece como «cubre todo». En master sigue apareciendo durante cinco minutos.

Verificación: npm run test, 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

Conflicto esperable con proyecto-web#71 (card 026): las dos ramas crean useUpdateOrder.test.tsx y tocan useUpdateOrder.ts en la misma mutación. Se resuelve quedándose con los cambios y los casos de las dos.

🤖 Generated with Claude Code

[TomasMartin2004]

Revisado. No lo mergearía para esta entrega.

El diagnóstico está bien: el stock por depósito se cachea cinco minutos, y si otra venta o un webhook se llevan esas unidades, confirmar la orden o guardar la modificación responde 422 «Insufficient stock» sin que nada refresque esa caché. useConfirmDraftOrder no invalidaba nada cuando la orden no llegaba a crearse.

Es molesto, pero hace falta que el stock se mueva por otro lado mientras el operador está en el formulario, y el sistema no queda mal: el 422 es correcto y la orden no se crea. El usuario puede recargar.

Lo agruparía con #70, #71 y #75 en una sola card de pulido para después de la entrega.