add-comment: support reply_to_id field in agent output for discussion threading

[corygehr]

Problem

When a workflow triggered by workflow_dispatch posts a comment to a Discussion via add-comment, the comment is always top-level. There's no way for the agent to specify which comment to thread under.

The replyToId logic in add_comment.cjs (line 593) only works for discussion_comment-triggered workflows:

 const replyToId = context.eventName === "discussion_comment" && !hasExplicitItemNumber 
   ? await resolveTopLevelDiscussionCommentId(githubClient, context.payload?.comment?.node_id) 
   : null;

This means any workflow triggered via dispatch-workflow — even one that receives a parent comment node ID as an input — cannot thread its reply.

Use case

We run a multi-level compliance agent system (CentralRepoOps pattern). When a reviewer posts /feedback on a specialist's Discussion comment:

1. Feedback workflow (triggered by discussion_comment) parses the command and identifies the specialist
2. Feedback workflow dispatches the specialist via dispatch-workflow with the target repo and context
3. Specialist re-evaluates and posts a 🔄 Updated reply to the Discussion

Step 3 always produces a top-level comment because the specialist runs under workflow_dispatch. The reviewer has to scroll to find it, and the Discussion thread becomes hard to follow.

We can already pass the parent comment node_id through dispatch inputs to the specialist — we just need a way for the specialist to hand it to the add-comment handler.

Proposed solution

Add optional reply_to_id field to the add-comment agent output message:

 {
   "type": "add_comment",
   "item_number": 240,
   "body": "🔄 Updated finding...",
   "reply_to_id": "DC_kwDOParentComment456"
 }

In add_comment.cjs, the handler would check message.reply_to_id when the event is NOT discussion_comment (or as a user-specified override):

 const replyToId = context.eventName === "discussion_comment" && !hasExplicitItemNumber
   ? await resolveTopLevelDiscussionCommentId(githubClient, context.payload?.comment?.node_id)
   : (message.reply_to_id || null);

The resolveTopLevelDiscussionCommentId helper should also be applied to message.reply_to_id to handle cases where the caller passes a reply node ID instead of a top-level one.

Context

• Request: Allow commenting, editing posts within a Discussion #23753 requested discussion reply threading → led to PR fix: thread discussion replies when add_comment triggered by discussion_comment event #23836 (auto-threading for discussion_comment triggers)
• [Issue] add-comment for Discussion doesn't allow for replies to a threaded comment reply #23944 fixed the reply-to-a-reply nesting issue → PR Fix discussion reply threading when triggering comment is itself a reply #24031 (shipped in v0.65.6)
• This request completes the chain: threading for workflow_dispatch-triggered workflows that know their target comment