fix: route Forgejo review comment updates to issue comment API

On Forgejo, the tracking comment for pull_request_review_comment events
is always created as a regular issue comment (because Forgejo's webhook
payload lacks the top-level comment object). The MCP server was
incorrectly setting isPullRequestReviewComment=true based on the event
name, causing every update to try pulls.updateReviewComment first —
which 404'd and silently swallowed Claude's responses.

Three fixes:
- MCP server: detect Forgejo and always use issue comment path
- update-comment-link: skip pulls.getReviewComment on Forgejo (saves
  one wasted 404 API call)
- update-claude-comment: expand fallback to also catch 422 (defense
  in depth for Forgejo edge cases)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

src/entrypoints/update-comment-link.ts

@@ -65,11 +65,13 @@ export async function updateCommentLink(
   try {
     // GitHub has separate ID namespaces for review comments and issue comments
     // We need to use the correct API based on the event type
-    if (isPullRequestReviewCommentEvent(context)) {
-      // For PR review comments, try the pulls API first.
-      // On Forgejo, the initial comment may have been created as a regular
-      // issue comment (because the payload lacks comment.id), so the pulls
-      // endpoint may 404. Fall through to issue comment fetch in that case.
+    //
+    // On Forgejo, the tracking comment is always an issue comment because
+    // Forgejo's pull_request_review_comment payload lacks the top-level
+    // `comment` object (so createInitialComment falls back to
+    // issues.createComment). Skip the pulls API attempt on Forgejo to avoid
+    // a wasted 404 round-trip.
+    if (isPullRequestReviewCommentEvent(context) && platform !== "forgejo") {
       try {
         console.log(`Fetching PR review comment ${commentId}`);
         const { data: prComment } = await octokit.rest.pulls.getReviewComment({