feat(ivr): persiste posição dos nós do editor visual entre recargas

Pedido do usuário: "faz a posição dos nós persistir entre recargas" —
o editor visual da PHASE 60 recalculava o layout do zero a cada carga
da página, perdendo qualquer arrasto manual assim que a tela recarregava.

`IvrMenu.entryPositionX/Y` + `IvrMenuOption.positionX/Y` (nullable,
puramente de apresentação — nunca entram no dialplan compilado, só no
layout do canvas). Salvos no banco, nunca localStorage: mesma convenção
do resto do app, estado compartilhado entre quem quer que edite o
tenant, não por navegador/dispositivo. "Salvar alterações" agora lê a
posição de verdade do estado de nós do @xyflow/react (reflete arrastos
feitos na sessão), não do estado de conteúdo das opções — os dois
tinham ficado dessincronizados desde a PHASE 60. Sem posição salva ainda
(menu novo, opção recém-adicionada), continua caindo num layout
automático em coluna.

Testado ponta a ponta: PATCH com coordenadas específicas (incluindo o
nó "Entrada"), GET de volta confirma os mesmos valores, e a página
carregada de novo com uma sessão real (cookie de login, não só a API
crua) já embute essas coordenadas nos props iniciais do componente.

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

TODO.md

@@ -2200,8 +2200,22 @@ para fazer o fluxo de maneira visual usando nodeRED")
       `PATCH` (a mesma chamada que o botão "Salvar" do editor visual
       faz) — confirmado no banco que a versão 2 do dialplan compilou as
       duas opções corretamente, superando a versão 1
-- [ ] Layout do canvas não persiste posição manual dos nós entre
-      recargas (recalculado a cada carga da página)
+- [x] **Layout do canvas agora persiste posição dos nós entre recargas**
+      (pedido do usuário: "faz a posição dos nós persistir entre
+      recargas") — `IvrMenu.entryPositionX/Y` + `IvrMenuOption.positionX/Y`
+      (nullable, puramente de apresentação, nunca entram no dialplan
+      compilado). Salvos no banco — nunca `localStorage`, mesma
+      convenção do resto do app (estado compartilhado entre quem edita
+      o tenant, não por navegador) — a cada "Salvar alterações", lendo
+      a posição de verdade do estado de nós do `@xyflow/react` (reflete
+      arrastos da sessão), não do estado de conteúdo das opções. Sem
+      posição salva ainda (menu novo, opção recém-adicionada), cai num
+      layout automático em coluna
+- [x] Testado ponta a ponta: `PATCH` com coordenadas específicas
+      (incluindo o nó "Entrada"), `GET` de volta confirma os mesmos
+      valores, e a página carregada de novo (SSR, cookie de sessão real)
+      já embute essas coordenadas nos props iniciais do componente —
+      não só a API, o carregamento real da tela também foi verificado
 
 ---