#3655: auto-reply: adicionar notificações automáticas de conclusão de tarefas

## Descrição Melhora o fluxo de execução de tarefas para que o Moltbot sempre notifique o usuário quando uma tarefa é concluída, mesmo quando o modelo não gera uma resposta final. ## Problema Atualmente, quando o Moltbot executa uma tarefa (via ferramenta/tool) mas o modelo não gera uma resposta final (payloads vazios), o usuário não recebe confirmação de que a tarefa foi concluída. O código simplesmente retornava `undefined` quando não havia payloads. ## Solução - **Rastreamento de ferramentas**: Adiciona rastreamento de ferramentas executadas com sucesso via eventos `tool` com fase `result` - **Confirmação automática**: Gera uma confirmação "✅ Concluído" quando não há payloads mas há ferramentas executadas - **Evita duplicação**: Não envia confirmação quando verbose está ligado (onToolResult já notifica via tool callbacks) - **Respeita heartbeats**: Não envia confirmação para heartbeats (que devem ser silenciosos) ## Arquivos Modificados - `src/auto-reply/reply/agent-runner-execution.ts` - Rastreamento de ferramentas executadas - `src/auto-reply/reply/agent-runner.ts` - Geração de confirmação automática ## Testes - ✅ Verificação de lint passou - ✅ Código compila sem erros - ✅ Lógica implementada conforme especificado no plano <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR adds a fallback user notification when an agent run executes tools successfully but produces no final reply payloads. It tracks successful tool call IDs during `tool` events (phase `result` without error) in `runAgentTurnWithFallback`, surfaces that set to the caller, and in `runReplyAgent` emits a simple "✅ Concluído" reply when there are zero payloads (and the run is not a heartbeat), avoiding the previous `undefined` silent outcome. The change fits into the existing reply pipeline by reusing the run loop’s event handling (where typing/tool events are already observed) and placing the confirmation logic at the same decision point where the system previously returned `undefined` after draining block/tool deliveries. <h3>Confidence Score: 4/5</h3> - This PR is largely safe to merge and addresses a real UX gap, with one logic guard that may suppress confirmations in some configurations. - Changes are localized and follow existing control flow (tool event handling + final payload decision). The main concern is using `shouldEmitToolResult()` as a proxy for whether tool-result notifications were actually delivered, which could cause the new confirmation to be skipped unexpectedly; otherwise behavior is straightforward and heartbeat handling is preserved. - src/auto-reply/reply/agent-runner.ts (confirmation gating condition); src/auto-reply/reply/agent-runner-execution.ts (event schema assumptions are minor). <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} **Context used:** - Context from `dashboard` - CLAUDE.md ([source](https://app.greptile.com/review/custom-context?memory=fd949e91-5c3a-4ab5-90a1-cbe184fd6ce8)) - Context from `dashboard` - AGENTS.md ([source](https://app.greptile.com/review/custom-context?memory=0d0c8278-ef8e-4d6c-ab21-f5527e322f13)) <!-- /greptile_comment -->