fix(v2): fix "Validar e executar" bug (real root cause), expand generic-phrase blacklist, add FORCE_SEND

Root cause found for why the real Slack message showed "→ Validar e
executar" for nearly every ACTIONABLE_NOW ticket: logic/message.js's
ACTION_LABELS map had a hardcoded entry for ACTIONABLE_NOW that always
won over the AI's actual next_action field in shortActionLabel(). The
AI's real, specific, already-validated-as-non-generic next_action (e.g.
"Realizar inventário das máquinas") was being silently discarded for
display purposes on every single message. Fixed by removing the
ACTIONABLE_NOW entry -- it now falls through to the existing
next_action-based fallback (already there, just unreachable for that
class before). UNASSIGNED_ACTIONABLE intentionally keeps its fixed
"Atribuir técnico" label -- that IS the correct display for that class.

logic/classification.js: expanded GENERIC_NEXT_ACTION_PHRASES with the
exact phrase that leaked through ("validar e executar") plus the
mission's additional list (validar chamado, prosseguir atendimento,
executar chamado, tratar chamado, analisar chamado). Bumped
AI_CLASSIFIER_VERSION 3->4 since this changes what next_action values
validate as non-generic -- forces reclassification of any cached
candidate that only passed under the older, narrower blacklist.

n8n/nodes/validate-ai-response.node.js: generic-next-action rejections
now get their own distinct fallback_reason ('generic_or_unsupported_
next_action') instead of being lumped into 'invalid_json', matching the
same pattern already used for the technician-vendor conflict.

logic/slack.js + logic/config.js: added FORCE_SEND (default false).
Manual-triggered runs now never send for real even with SEND_ENABLED=
true in production, unless FORCE_SEND is also explicitly set -- protects
against someone clicking "Execute Workflow" in production and
accidentally re-sending today's digest.

Added format-safety regression tests (no literal backslash-n, URL never
bleeds into the next item's id, no markdown-wrapped URLs) -- verified
these were never actually triggered in a real send (the reported
corruption was n8n's raw JSON data-inspector view, not a delivered
Slack message; both manual runs in question had shouldSend:false).

169/169 tests passing.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

logic/slack.test.js

@@ -56,6 +56,28 @@ test('evaluateSendGuard: envio duplicado e bloqueado -- teste obrigatorio #15',
   assert.equal(result.reason, 'already_sent');
 });
 
+test('runType manual NAO envia mesmo com SEND_ENABLED=true, a menos que FORCE_SEND tambem esteja ligado -- missao "correcao final" secao 16', () => {
+  const result = evaluateSendGuard({
+    config: { sendEnabled: true, forceSend: false }, existingRecords: [], reportDate: '2026-08-25', runType: 'manual', messageHash: 'abc',
+  });
+  assert.equal(result.shouldSend, false);
+  assert.equal(result.reason, 'manual_run_needs_force_send');
+});
+
+test('runType manual envia quando FORCE_SEND esta explicitamente ligado -- missao "correcao final" secao 17', () => {
+  const result = evaluateSendGuard({
+    config: { sendEnabled: true, forceSend: true }, existingRecords: [], reportDate: '2026-08-25', runType: 'manual', messageHash: 'abc',
+  });
+  assert.equal(result.shouldSend, true);
+});
+
+test('runType scheduled envia normalmente com SEND_ENABLED=true, independente de FORCE_SEND', () => {
+  const result = evaluateSendGuard({
+    config: { sendEnabled: true, forceSend: false }, existingRecords: [], reportDate: '2026-08-25', runType: 'scheduled', messageHash: 'abc',
+  });
+  assert.equal(result.shouldSend, true);
+});
+
 test('evaluateSendGuard: retry (mensagem diferente) apos falha anterior nao e bloqueado', () => {
   const existing = [{ report_date: '2026-08-25', run_type: 'scheduled', message_hash: 'abc', status: 'failed' }];
   const result = evaluateSendGuard({ config: { sendEnabled: true }, existingRecords: existing, reportDate: '2026-08-25', runType: 'scheduled', messageHash: 'abc' });