feat(dialer): CPS Limiter + Predictive Dialer Engine

Fecha agente.md secao 72-86 (motor preditivo) e 77-79 (CPS distribuido,
reserva de leads, lock de campanha). Uma campanha RUNNING agora origina
chamadas sozinha, respeitando capacidade de agentes, CPS hierarquico e
taxa de abandono — sem intervencao manual.

Deliberadamente fora do escopo (agente.md secao 72: "nao e' so' `for lead
-> originate`"): mod_avmd (opcional), callbacks agendados, disposicoes de
agente — ficam pra fase CDR.

## Novo servico apps/predictive-dialer

Mesmo padrao arquitetural de fs-events/fs-config: Node standalone em
Docker, ESL propria, tick a cada 2s sobre tenants ativos x campanhas
RUNNING/WAITING_SCHEDULE.

- Lock de campanha (dialer:campaign:{id}, secao 79): TTL/ownership/
  renewal/safe-release via Lua compare-and-delete.
- CPS distribuido (secao 77, 62): token bucket janela 1s, hierarquia
  GLOBAL/TENANT/TRUNK/CAMPAIGN numa unica chamada Lua atomica — nivel
  esgotado bloqueia todos SEM incremento parcial dos que passariam.
- Reserva atomica de leads (secao 78): FOR UPDATE SKIP LOCKED dentro da
  mesma transacao withTenantContext.
- CallAttempt/CampaignStats (schema novo): state machine da chamada
  (secao 82) + EWMA (secao 75) de answer_probability/average_answer_delay/
  average_talk_time/abandon_rate por campanha.
- Capacidade em tempo real + pacing (secao 73-76, 84-85): conta agentes
  por estado via Tier->Agent.state, previsao de liberacao (horizonte
  unico de 15s, simplificacao documentada dos 4 buckets da especificacao),
  controle de abandono reduz pacing progressivamente, nunca origina sem
  capacidade prevista.

## Modo simulacao (secao 185-186)

DIALER_SIMULATION=true (default, ja estava no .env desde o inicio da
sessao) sorteia ANSWER/BUSY/NO_ANSWER/FAILED em software, sem PSTN real.
So' quando ANSWERED e' que uma chamada sintetica (null/dummy, sem PSTN)
entra na fila real via mod_callcenter de verdade — escolha deliberada pra
maximizar codigo real exercitado em vez de simular tudo em memoria. Os
identificadores da secao 81 (b2bcall_tenant_id/call_id/attempt_id/
campaign_id/lead_id) vao como channel variables nessa perna, entregando
tenantId real no WebSocket sem fan-out.

Real Outbound Safety (secao 186): as duas flags checadas no boot, nunca
ativadas automaticamente — caminho PSTN real implementado mas nunca
exercitado (sem trunk/operadora real neste laboratorio).

## Dois bugs reais achados e corrigidos testando esta fase

- Perna sintetica (null/dummy) nao tem midia do outro lado — nunca
  desligava sozinha depois de bridgear com um agente. Corrigido com
  hangup agendado via uuid_kill no talk_time simulado.
- Corrida entre queue:sync e tier:sync (dois canais Redis independentes,
  sem ordem garantida): atribuir tier logo depois de criar a fila podia
  rodar tier add antes do queue reload terminar ("-ERR Queue not found!",
  erro real, diferente do ja conhecido "already exist"). Corrigido com
  retry curto (ate 3 tentativas) em agent-sync.ts::addTierWithRetry.

## GET /campaigns/:id/stats

Secao 227.7 "visualizar pacing" — CampaignStats + agentes por estado +
calls em andamento, sem esperar a fase Frontend.

Verificado ponta a ponta: campanha RUNNING originando 3 tentativas por
tick, outcomes simulados corretos com retry agendado (BUSY 15min/
NO_ANSWER 60min/FAILED 30min), uma tentativa ANSWERED completando o ciclo
real inteiro (fila -> agente -> bridge -> hangup -> EWMA atualizada),
stop nao derruba chamada ativa (secao 66), calls_answered=3 confirmado no
`queue list` do FreeSWITCH. CPS limiter e lock de campanha testados
isoladamente (hierarquia sem incremento parcial, ownership nunca
roubado). typecheck do workspace inteiro limpo.

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

apps/predictive-dialer/src/lead-reservation.ts

@@ -0,0 +1,51 @@
+import type { Prisma } from "@b2bcall/database";
+
+export interface ReservedLead {
+  id: string;
+  phoneNormalized: string;
+  name: string | null;
+  attemptCount: number;
+}
+
+/**
+ * Reserva atômica de leads (agente.md secao 78): `FOR UPDATE SKIP LOCKED`
+ * garante que dois workers concorrentes nunca pegam o mesmo lead — quem
+ * chegar primeiro tranca a linha, o outro pula pra próxima em vez de
+ * esperar (nada de fila de espera aqui, é melhor originar outro lead do
+ * que travar o tick inteiro). `count` normalmente é pequeno (poucas
+ * unidades por tick), então `SELECT ... LIMIT` é barato mesmo sem índice
+ * dedicado além do já existente em `(campaign_id, status, next_attempt_at)`.
+ *
+ * Precisa rodar dentro do MESMO `withTenantContext` transaction que fez a
+ * checagem de RLS — o lock de linha só vale até o commit/rollback da
+ * transação atual.
+ */
+export async function reserveLeads(
+  tx: Prisma.TransactionClient,
+  tenantId: string,
+  campaignId: string,
+  count: number,
+): Promise<ReservedLead[]> {
+  if (count <= 0) return [];
+
+  const rows = await tx.$queryRaw<ReservedLead[]>`
+    SELECT id, phone_normalized AS "phoneNormalized", name, attempt_count AS "attemptCount"
+    FROM leads
+    WHERE tenant_id = ${tenantId}::uuid
+      AND campaign_id = ${campaignId}::uuid
+      AND status IN ('NEW', 'READY')
+      AND (next_attempt_at IS NULL OR next_attempt_at <= now())
+    ORDER BY next_attempt_at ASC NULLS FIRST, created_at ASC
+    LIMIT ${count}
+    FOR UPDATE SKIP LOCKED
+  `;
+
+  if (rows.length === 0) return [];
+
+  await tx.lead.updateMany({
+    where: { id: { in: rows.map((r) => r.id) } },
+    data: { status: "RESERVED" },
+  });
+
+  return rows;
+}