Slackbot: dedupe only the root message; process replies normally

[zzstoatzz]

Problem\n- After merging the previous PR, follow-up messages in the same thread were skipped as duplicates.\n- Root cause: the idempotency key (root thread_ts) was used to gate all events in the thread, so once a status row existed, later events (including legitimate replies) failed acquisition and were treated as duplicates.\n\nFix\n- Dedupe ONLY the root message (when event.thread_ts is None).\n - Acquire/mark-completed only for the root.\n - While in progress: edits to the root get a polite "still working" note.\n - After completion: duplicate root deliveries are skipped.\n- Replies (messages with event.thread_ts present) are not gated and are processed normally.\n\nNotes\n- Keeps the tiny SQLite status in _internal/thread_status.\n- Minimal changes to api.py; retains the existing user-facing behavior for edit notices.\n- Lint/format pass.\n\nHappy to adjust behavior if you want replies during in-progress to be queued or coalesced instead of processed immediately.

[Copilot]

Pull Request Overview

This PR fixes a bug where Slack thread replies were incorrectly being treated as duplicates and skipped after the root message was processed. The fix modifies the deduplication logic to only gate root messages while allowing replies to be processed normally.

• Modified deduplication to only apply to root messages (when event.thread_ts is None)
• Added conditional logic to only acquire/mark completion for root messages
• Updated error messages to clarify they apply specifically to root events

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

Using 'is_root_message' in locals() is fragile and could break if the variable declaration is moved. Consider restructuring the code to avoid this check, perhaps by moving the completion logic inside the if is_root_message: block or using a different approach to track whether completion is needed.