feat(rotas-entrada): dropdown de destino real (ramal/IVR/fila/grupo)

Pedido do usuário: "em vez de o campo de destino ser aberto tem que ter
um dropdown listando todos os ramais do tennant e tb todas ivr e filas
e grupos de ramais do tennant" — até aqui o destino era texto livre.

Construir o dropdown revelou que fila e grupo NUNCA tinham sido
implementados de verdade como destino possível — só ramal/IVR
funcionavam. Oferecer as duas opções sem o mecanismo por trás seria
mostrar um dropdown mentiroso, então:

InboundRoute.destinationType (novo enum EXTENSION/IVR/QUEUE/CALL_GROUP)
decide como buildInboundRouteXml interpreta o destino:
- EXTENSION/IVR: inalterado, o mesmo transfer já testado (PHASE 56/58).
- QUEUE: destinationNumber guarda o Queue.id; a resolução de entrada
  emite `answer` + `callcenter data="<queueId>@<domain>"` direto, sem
  tocar no dialplan "default". `callcenter` entrou no allowlist de
  applications com o mesmo risco zero de `pickup`.
- CALL_GROUP: destinationNumber guarda o Extension.callGroup; a
  resolução consulta AGORA (nunca um snapshot salvo) todos os ramais
  com esse callGroup e emite um `bridge` multi-leg — toca todos ao
  mesmo tempo, quem atender primeiro cancela os outros. Trocar quem
  está no grupo depois de criar a rota já vale na próxima chamada.

Testado ponta a ponta com chamadas reais nos 2 mecanismos novos: fila —
softphone externo discou o DID, show channels confirmou a chamada
dentro da application callcenter com o nome certo da fila; grupo — 2
ramais reais no mesmo callGroup, a chamada tocou nos DOIS ao mesmo
tempo (mesmo call_uuid, ambas RINGING), atender em um cancelou o outro
automaticamente — ring group de verdade.

Tela: "Tipo de destino" + um segundo dropdown com as opções reais do
tenant pra cada tipo (ramais, menus de IVR, filas, ou os valores
distintos de callGroup já usados em algum ramal). Testado com
Playwright: os 4 tipos aparecem, e trocar o tipo atualiza as opções do
segundo dropdown corretamente.

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

docs/INBOUND_ROUTES.md

@@ -215,15 +215,56 @@ ponta: `PATCH` com coordenadas específicas, `GET` de volta confirma os
 mesmos valores, e a página carregada de novo (SSR) já embute essas
 coordenadas nos props iniciais do componente.
 
+## Dropdown de destino: ramal, IVR, fila ou grupo (PHASE 62)
+
+Achado real reportado pelo usuário: o destino de uma rota de entrada era
+um campo de texto livre — sem dropdown, e (descoberto construindo o
+dropdown) fila/grupo nunca tinham sido implementados de verdade como
+destino possível, só ramal/IVR funcionavam.
+
+`InboundRoute.destinationType` (novo enum: `EXTENSION`/`IVR`/`QUEUE`/
+`CALL_GROUP`) decide como `buildInboundRouteXml` interpreta o destino:
+
+- **EXTENSION/IVR**: comportamento inalterado — `transfer` pro contexto
+  do tenant, reaproveitando o dialplan já testado (PHASE 56/58).
+- **QUEUE**: `destinationNumber` guarda o `Queue.id`. A resolução de
+  entrada emite `answer` + `callcenter data="<queueId>@<domain>"`
+  direto — nunca passa pelo dialplan "default" nem precisa de nenhuma
+  regra nova lá. `callcenter` entrou no allowlist de applications
+  (`packages/telephony/src/dialplan-xml.ts`) com o mesmo risco zero de
+  `pickup` — só recebe `<queueId>@<domain>` como texto.
+- **CALL_GROUP**: `destinationNumber` guarda o valor de
+  `Extension.callGroup`. A resolução de entrada consulta AGORA (nunca um
+  snapshot salvo na criação da rota) todos os ramais do tenant com esse
+  `callGroup` e emite `bridge` com uma leg por ramal
+  (`user/A@domain,user/B@domain,...`) — toca todos ao mesmo tempo, quem
+  atender primeiro cancela os outros (ring group de verdade). Trocar
+  quem está no grupo depois de criar a rota já vale na PRÓXIMA chamada,
+  sem precisar re-salvar nada — a query roda a cada chamada de entrada,
+  não uma vez só.
+
+Testado ponta a ponta com chamadas reais nos 2 mecanismos novos: fila —
+softphone externo discou o DID, `show channels` confirmou a chamada
+dentro da application `callcenter` com o nome certo da fila; grupo — 2
+ramais reais registrados no mesmo `callGroup`, a chamada tocou nos DOIS
+ao mesmo tempo (mesmo `call_uuid`, ambas as legs `RINGING`), atender em
+um cancelou o outro automaticamente.
+
+Tela "Rotas de Entrada": "Tipo de destino" (Ramal/IVR/Fila/Grupo de
+ramais) + um segundo dropdown listando as opções reais do tenant pra
+cada tipo (ramais cadastrados, menus de IVR, filas, ou os valores
+distintos de `callGroup` já usados em algum ramal).
+
 ## O que falta
 
 - Sem TTS (texto→voz) — só upload de arquivo WAV já gravado.
 - Menu de IVR não suporta sub-menus (uma opção levando a OUTRO IVR) nem
-  destino "fila" — só ramal, dentro do contexto `default`.
-- Tela de frontend "Rotas de Entrada" cobre só CRUD simples (DID →
-  ramal); não tem seletor dedicado de "IVR" como destino ainda (o
-  operador digita o contexto/`ivr_entry` manualmente, mostrados na
-  própria tela de IVR pra copiar).
+  destino "fila" — só ramal, dentro do contexto `default`. Rota de
+  entrada já suporta fila/grupo, mas um MENU de IVR ainda só bridge pra
+  ramal.
+- Grupo de ramais só é alcançável por Rota de Entrada — não existe (e
+  não foi pedido) um jeito de discar um grupo de dentro do próprio
+  dialplan "default" via feature code.
 - Perda das proteções de toll-fraud do `public.xml` vanilla (unroll de
   loop de chamada, etc.) — não replicadas no contexto `inbound` novo.
   Aceitável pra esta fase (sem trunks reais ainda), mas revisar antes de