`github_inline_comment` MCP server cannot reply to an existing review comment thread

### Context

We use `claude-code-action@v1` for automated PR review. The review prompt asks the
reviewer to keep discussions tidy: when it has already commented on a piece of code,
reply inside that existing review thread rather than opening a duplicate top-level
comment, and when a concern has been addressed, post a short confirmation and resolve
the thread.

### Problem

There is no tool for posting a threaded reply to an existing review comment.

- `create_inline_comment` (`src/mcp/github-inline-comment-server.ts`) only creates a
*new* inline comment. Its parameters are `path`, `body`, `line`, `startLine`,
`side`, `commit_id`, `confirmed` — there is no reply target.
- `src/mcp/github-comment-server.ts` registers only `update_claude_comment`.
- Both are unchanged on `main`.

I understand the inline-comment server is intentionally minimal — the header comment
says it exists so Claude "can't accidentally approve a PR", which is a good
constraint. Replying within a thread doesn't grant approval capability, so it seems
compatible with that intent.

### The Bash fallback is denied

The only remaining route is shelling out:

```
gh api --method POST repos/{owner}/{repo}/pulls/{n}/comments/{comment_id}/replies -f body='...'
```

This is denied by the permission layer even with a matching rule present in
`--allowedTools`:

```
Bash(gh api --method POST repos/{owner}/{repo}/pulls/{n}/comments:*)
```

Denial payload from the run log:

```json
{
"subtype": "permission_denied",
"tool_name": "Bash",
"decision_reason_type": "other",
"decision_reason": "This command requires approval",
"message": "This command requires approval"
}
```

Observations that may or may not be related, offered as data rather than a diagnosis:

- `Bash(gh pr comment:*)` is also allowlisted and is *also* denied when the `--body`
value spans multiple lines. The summary comment still appears, because the reviewer
falls back to `update_claude_comment`.
- `Bash(gh api graphql:*)` works — the `resolveReviewThread` mutation succeeds
reliably.
- The denied reply bodies contained markdown backticks; the denied `gh pr comment`
bodies contained newlines. I could not establish whether argument content is
actually the discriminator, and some non-allowlisted read-only commands
(`ls … && grep …`) are permitted, which suggests more than one code path.

### Net effect

Thread *resolution* works while the acknowledging reply does not, so threads get
resolved silently with no explanation to the contributor — worse than not resolving
them. In CI there is no human available to grant the interactive approval, so the
instruction is unsatisfiable and we are removing it from our prompt.

### Ask

1. Add reply support to the inline comment server — either an optional
`in_reply_to_id` on `create_inline_comment`, or a separate
`reply_to_review_comment` tool. Structured arguments would sidestep shell quoting
entirely, which is the main attraction.
2. Secondary: consider making the denial reason more specific than
`"This command requires approval"` — naming the rule that was expected to match, or
why matching failed. Debugging an `--allowedTools` rule in CI is currently guesswork,
since the one place a human could learn the reason is an approval prompt that never
appears.

### Version

`claude-code-action@v1` (pinned to a v1.0.189 commit SHA); also verified against
`main` for the MCP server sources.