fix(slack): stop sending thread_id to decopilot — it rejects unknown ids

[JonasJesus42]

Summary

Follow-up to #435/#436. The temp-thread_id retry from #435 still fails in production with Thread not found: <name>-<timestamp> — the decopilot endpoint rejects any unknown thread_id, including the temp fallback. The retry just postponed the same error.

Drop thread_id from the request entirely. Without it, the decopilot allocates a fresh thread per call. The slack-mcp already rebuilds conversation context from Slack history on every webhook (buildContextMessages → 1 system message), so the agent stays coherent within a Slack thread/DM without depending on decopilot-side memory.

The userName → threadId plumbing is kept upstream in llm-handler.ts / eventHandler.ts so we can plug a real thread-create call (cached id per user) later if per-person decopilot memory becomes important.

Test plan

• Send a DM → pod logs show [LLM] streamAgent <url> (no thread_id).
• Bot replies on first message (no more 500 Thread-not-found).
• Slack thread context survives within a thread (verified by sending a 2nd message referencing the first — context comes from buildContextMessages, not decopilot memory).
• Unrelated agent failures still fall back to the trigger publish as before.

---

Summary by cubic

Stop sending thread_id to decopilot to eliminate “Thread not found” errors; each call now creates a fresh decopilot thread while Slack-side context continues to be rebuilt per webhook.

• Bug Fixes
  • Strip thread_id before calling streamAgent; log now shows “(no thread_id)”.
  • Removed temp thread_id retry and access-failure heuristics to avoid repeated 500s.
  • Left upstream userName → threadId plumbing intact for a future thread-create flow.

^{Written for commit 160b632. Summary will update on new commits.}