fix(slack): revert to /decopilot/stream — /runtime/stream requires taskId

[JonasJesus42]

Summary

Follow-up to #436/#437. Real traffic on the /decopilot/runtime/stream endpoint hits streamCore: taskId is required — that endpoint is the resume-a-task path used internally by the AgentOf binding when there's already an upstream task. For our chat-like webhook flow there is no taskId.

Revert to /api/<org>/decopilot/stream — the user-facing chat endpoint studio's own UI uses — and parse its custom SSE stream locally instead of going through the runtime's streamAgent helper. We still omit thread_id (decopilot rejects ids it did not mint).

The userName → threadId plumbing in llm-handler.ts / eventHandler.ts stays in place so we can wire a real thread-create call later if per-person decopilot memory becomes a requirement.

Test plan

• Send a DM → pod logs show [LLM] POST <meshUrl>/api/<org>/decopilot/stream and the bot replies.
• No more streamCore: taskId is required errors.
• Slack-thread context survives within a thread (proved by sending a follow-up — context comes from buildContextMessages, not decopilot memory).

---

Summary by cubic

Reverted Slack MCP LLM streaming to the chat endpoint to stop taskId is required errors and restore replies. We now call /api/<org>/decopilot/stream directly and parse its SSE output locally.

• Bug Fixes
  • Switched from /decopilot/runtime/stream to /decopilot/stream so no pre-existing taskId is needed.
  • Replaced streamAgent from @decocms/runtime/decopilot with a direct fetch and lightweight SSE parser.
  • Continue omitting thread_id; context comes from Slack history. Kept userName → threadId plumbing for future thread creation.

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