fix(precios): nada se guarda solo -- cambios pendientes y un unico guardado

Reescritura de la edicion de la rejilla. Julio, en produccion: «antes salio un
guardar, ahora no, y si te sales de la celda no lo guarda. Es muy irregular».

EL MODELO
Editar acumula CAMBIOS PENDIENTES. Escribir ocurre en un solo sitio: el boton
Guardar de la barra de abajo, que esta SIEMPRE ahi (con 0 cambios sigue puesto,
apagado). Guardar abre la previsualizacion y escribe UNA operacion con las N
entradas, reversible entera.

Las teclas, sin excepciones: Enter acepta y baja · Tab acepta y va a la derecha ·
salir de la celda acepta tambien · Esc descarta esa edicion y no toca las demas ·
campo vacio acepta «volver a heredado». Salvo Esc, todo lo tecleado se queda
pendiente: nunca se pierde y nunca se escribe sin pasar por Guardar.

La operacion en lote alimenta LA MISMA lista de pendientes en vez de tener su
propio guardado. Dos caminos de guardado era justo lo que producia «a veces sale
un guardar y a veces no».

DOS COSAS QUE HABRIAN ROTO LA PANTALLA, ENCONTRADAS AL IMPLEMENTAR

1. useBlocker de react-router LANZA fuera de un data router, y esta app monta
   <BrowserRouter>. Usarlo para el aviso de salida habria matado la pantalla en
   el primer render con un cambio pendiente. Sustituido por un escuchador en
   fase de captura sobre los enlaces + beforeunload, sin tocar el armazon.
   Queda un hueco declarado: el boton Atras del navegador y el Atras fisico de
   Android no pasan por ahi.

2. Aceptar al salir de la celda no puede leer el estado de React: va un render
   por detras. Ahora onBlur lee el DOM, y Esc devuelve al campo el valor con el
   que se abrio, con lo que el onBlur del desmontaje se vuelve inocuo. Sin
   indicadores de «estoy escapando» que consultar.

EL AMBITO (§3)
Investigado: el guardado lee UN solo `locationId`, y el `location_id` escrito y
el `ambito` del scope salen de esa misma variable, asi que no pueden discrepar
entre si. El cliente tenia ambito cuenta de verdad; no he encontrado ningun
camino por el que el selector se lea mal. Lo que faltaba era que la pantalla lo
DIJERA donde se mira antes de escribir: ahora el ambito aparece por su nombre en
la barra de guardado, en el titulo de la previsualizacion y en el propio boton
(«Guardar en Foodint Alcala»). Ademas el scope guarda `ambito_location_id`.
Y cambiar de marca o de ambito con pendientes pide confirmacion en vez de
tirarlos en silencio, que es como se perdia el trabajo al intentar corregirlo.

De paso: la consulta de locales ya no se traga su error. Si fallaba, el
desplegable se quedaba con «toda la cuenta» como unica opcion y era imposible
escribir en un local sin que nadie entendiera por que.

FORMATO (§4)
Se usan fmtMoney y fmtNumEs de src/lib/format.ts, que existian para esto: dos
decimales y simbolo al mostrar, coma sin simbolo al sembrar el campo. Antes se
sembraba con String(precio) y salia «15,9» al lado de «15,90 €». El comentario
de fmtNumEs describe ese fallo literalmente; no haberla usado fue el error.

VERIFICADO
- Build (npm run build), lint y las 18 pruebas puras en verde.
- En el laboratorio, una operacion de 2 entradas con ambito local: UNA fila en
  price_operation con entries_count=2, DOS en el historial con el MISMO
  operation_id, y los dos overrides con location_id = Alcala, no NULL. Revertida
  despues; el laboratorio queda sin overrides de local.
- Cero trafico a HubRise y Last.

Lo que necesita abrir la pantalla (gestos, barra, aviso de salida) queda para
la verificacion de Julio: es la leccion de la entrega anterior.

VENTANA: esto dispara OTA y la de hoy se cerro a las 12:15. Va en la rama, SIN
mergear a main. El workflow solo construye en push a main, asi que aqui no
despliega nada. Mergear despues de las 23:45 o manana antes de las 12:15.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Vy4yW6xBAtXcaSGgKybquB

Author: claude

docs/precios_revert_meraki_pita_20260818.sql

@@ -0,0 +1,31 @@
+-- PREPARADO, NO EJECUTADO. Espera a que Julio lo diga (encargo del 18/08, §6).
+--
+-- Las dos ediciones de Meraki Pita del 18/08 12:50 se escribieron en ambito
+-- CUENTA, no en Alcala. Eso significa que 15,90 EUR vale tambien para
+-- Carabanchel, porque un precio de cuenta es el precio de los dos locales.
+--
+--   34abc60d-493e-46a1-9bd5-c40da313bd69  Glovo  13,90 -> 15,90
+--   5cc67946-9377-4de6-9dac-11c0a4c9f2c6  Uber   13,90 -> 15,90
+--   producto: The Mixed Master: Pita Mixta Gyros
+--
+-- NO se revierten por iniciativa propia: puede que 15,90 le valga para los dos
+-- locales, y en ese caso deshacerlo seria cambiarle el precio sin permiso.
+--
+-- Si decide deshacerlas, esto las devuelve a 13,90 en los dos canales. Cada
+-- revert escribe una operacion NUEVA (kind='revert'); no borra historial.
+-- Ejecutar con la sesion de un admin de Foodint, no con service_role: la RPC
+-- comprueba permisos con auth.uid().
+--
+-- Si decide QUEDARSE con 15,90 pero solo en Alcala, el camino es otro: revertir
+-- estas dos y volver a escribirlas con el ambito puesto en Alcala desde la
+-- rejilla, ahora que la barra de guardado dice donde escribe.
+
+-- select public.revert_price_operation('34abc60d-493e-46a1-9bd5-c40da313bd69'::uuid);
+-- select public.revert_price_operation('5cc67946-9377-4de6-9dac-11c0a4c9f2c6'::uuid);
+
+-- Comprobacion posterior:
+-- select o.location_id, o.price, sc.name as canal
+--   from menu_item_override o
+--   join sales_channel sc on sc.id = o.channel_id
+--  where o.menu_item_id = (select menu_item_id from menu_item_override_history
+--                           where operation_id = '34abc60d-493e-46a1-9bd5-c40da313bd69' limit 1);