chore: avaliar migração de pnpm para bun (spike) (P5)

[gvieira18]

Status: épico ainda NÃO grelhado. Este issue é só o problema em si, para servir de ponto de partida do grilling.

P5 (roadmap: P1 pairing-code / P2 polls #16 / P3 auth-store #17 / P4 Discord #18 / P5 este). É um spike de avaliação — o resultado pode ser "NÃO migrar". Nada de migrar sem o veredito do grill.

Problem Statement

O toolchain hoje é um mosaico em cima do Node: pnpm (package manager) + tsx (dev/run TS) + tsup (build ESM) + node:test via tsx (tsx --test) + node (runtime do serviço em prod, systemd --user). São várias ferramentas com sobreposição de responsabilidade. O bun promete unificar isso (PM + runtime + test runner + bundler) com instalação/execução mais rápidas.

Falta avaliar se migrar (parcial ou total) pro bun compensa neste projeto, ou se o risco/atrito supera o ganho. Não há decisão — há a pergunta.

Escopo do spike (o que medir/decidir no grill)

Bun pode substituir camadas independentes; a avaliação deve tratar cada uma:

• PM (pnpm → bun install): lockfile, workspaces (o repo tem workspaces: ["."]), velocidade real.
• Runtime (node dist/index.js → bun dist/index.js ou rodar .tsx direto): impacta o ExecStart da unit systemd (hoje node absoluto via command -v node, ver chore: Makefile targets for systemd --user service lifecycle #10) e o footgun de PATH.
• Dev/build (tsx/tsup → bun nativo: bun --watch, bun build): ainda precisa de ESM; conferir saída equivalente.
• Testes (tsx --test / node:test → bun test): a suíte usa a API node:test (import { test } from 'node:test') — migrar pro runner do bun é reescrita não-trivial dos imports/asserts.

Riscos / pontos de compatibilidade (a validar)

• Deps nativas: better-sqlite3 (N-API) — roda no bun? Ou trocar por bun:sqlite? Isso cruza com o refactor: auth store da sessão Baileys em SQLite (auth.db) (P3) #17 (auth store SQLite) e o outbox.db.
• Baileys (@whiskeysockets/baileys), Ink/React (TUI), pino: compat com o runtime do bun (event loop, streams, workers).
• Prod primeiro: o serviço 24/7 é o alvo mais sensível — validar bun como runtime headless antes de qualquer coisa na TUI.
• CI / .github/workflows: setup-node → setup-bun; caches; auto-merge.

Critério de decisão (a definir no grill)

• Ganho concreto (tempo de install/CI/boot) vs custo (reescrita de testes, risco de dep nativa, maturidade em prod).
• Migração pode ser parcial (ex.: só PM, mantendo node no runtime) — avaliar o caminho incremental, não só tudo-ou-nada.

Fora do escopo

• Executar a migração em si — isto é só a avaliação. A implementação (se aprovada) vira épico próprio.