GOVA SOFT CHAT V3.73 — CORREÇÃO PROFUNDA DA RECEPÇÃO E PÓS-ATENDIMENTO

DIAGNÓSTICO ESTRUTURAL
Foram encontrados três pontos que permitiam o ticket voltar ao setor errado:

1) post_service_return_department_id ainda podia fixar todo RETORNO em um setor,
   inclusive Comercial, antes da nova triagem.

2) Depois da correção inicial do setor, a mesma mensagem continuava passando por
   CommercialSalesService, FlowEngine e AIEngine. Uma dessas camadas podia mudar
   novamente o departamento antes do fim da requisição.

3) A "guarda final" não era suficiente porque existem rotinas do webhook que
   encerram a requisição antes dela chegar ao fim (json_response antecipado).

NOVA ARQUITETURA
A Recepção agora é AUTORITATIVA.

Mensagem atual
-> classificador central
-> setor atual confirmado no banco
-> limpa estados incompatíveis do setor anterior
-> despacha a solicitação no setor correto
-> encerra a Recepção nessa mesma requisição

Nenhum motor antigo pode reclassificar a mesma mensagem depois.

PÓS-ATENDIMENTO
- "oi", "ok", "obrigado" etc. dentro de 2h continuam silenciosos.
- pedido real gera RETORNO.
- RETORNO NÃO usa setor anterior.
- RETORNO NÃO usa mais post_service_return_department_id como prioridade.
- se a mensagem já é clara, o NOVO ticket nasce diretamente no setor atual:
  "sem internet" -> Suporte
  "fatura" -> Financeiro
  "renegociar dívida" -> Financeiro
  "planos" -> Comercial
- se o assunto não estiver claro, nasce na Recepção.

FINANCEIRO
- boleto/fatura/pagamento -> Financeiro + fluxo de cobrança
- PIX -> Financeiro + fluxo PIX
- renegociação/dívida/falar com financeiro -> fila humana Financeiro

SUPORTE
- primeiro roteia definitivamente para Suporte e encerra a Recepção.
- a próxima mensagem já será processada dentro do Suporte.

COMERCIAL
- direciona definitivamente ao Comercial.
- a pergunta pode ser entregue ao CommercialSalesService, mas a Recepção não
  continua depois para sobrescrever o setor.

LIMPEZA DE ESTADO
Ao trocar de setor:
- remove commercial_sales_states quando sai de Comercial;
- remove billing_flow_states quando sai de Financeiro;
- remove ticket_flow_states antigo para não trazer a próxima etapa do setor anterior;
- limpa locks comerciais incompatíveis.

AUDITORIA
Nova tabela ticket_routing_events registra:
- ticket
- setor anterior
- setor escolhido
- intenção
- origem do roteamento
- trecho da mensagem
- resultado/verificação

Isso permite identificar exatamente qualquer novo desvio sem adivinhar.

APLICAÇÃO
Aplicar por cima da V3.72.
