Feature: allow review comments on any file line, not just lines within the diff

Commencez par lire les points d’entrée add_comment_to_pending_review et pull_request_review_write, puis reproduisez le workflow de revue en attente décrit dans l’issue avec un commentaire en dehors du diff. Suivez la manière dont submit_pending gère ces commentaires et dont la mutation GraphQL addPullRequestReviewThread accepte path et line. Le travail est terminé lorsque l’échec est signalé ou que les commentaires sur des lignes arbitraires de fichiers sont conservés inline, tout en laissant le workaround existant au niveau du fichier disponible.

Describe the feature or problem you'd like to solve

When using add_comment_to_pending_review to leave a code review, the comment is silently dropped at submit time if the targeted line is outside the PR's diff hunks (e.g., unchanged context further up the file). The tool returns success on add_comment_to_pending_review, but pull_request_review_write { method: "submit_pending" } accepts the review without that comment ever appearing on the PR.

This means agents reviewing PRs cannot leave inline comments on file context that is relevant to a change but happens to sit outside the modified lines — for example, stale JSDoc on an exported interface that should be updated to reflect a new feature added several lines below.

In the GitHub web UI, a human reviewer can expand context and click any line in any file to add a comment. Agents using this MCP server cannot match that capability.

Proposed solution

Two parts:

1. Surface the failure. When a comment is dropped because the targeted line is outside the diff, return an error from add_comment_to_pending_review (or surface it on submit) so the agent can fall back to subjectType: "FILE" or a top-level comment. Today the tool reports success and the rejection happens silently inside GitHub's submit step.

2. Support arbitrary file lines. Use the GraphQL addPullRequestReviewThread mutation (which accepts path + line without requiring a diff position) when the requested line is outside the unified diff. This would give agent reviewers the same expressive power as human reviewers in the UI.

Example prompts or workflows (for tools/toolsets only)

1. "Review this PR — flag any stale JSDoc/comments on exported APIs whose contract changed." Today the agent can correctly identify stale documentation but cannot leave the inline comment if the JSDoc itself isn't in the diff.
2. "Suggest renames for the helper functions used by the new code." If the helpers themselves are unchanged, the agent can't comment on them inline.
3. "Note any security-relevant invariants the changes rely on." Often these are documented elsewhere in the file, outside the diff.

Additional context

Repro:

1. Open any PR with a small, localized diff.
2. Use pull_request_review_write { method: "create" } to start a pending review.
3. Use add_comment_to_pending_review targeting an unchanged line ≥30 lines from the diff. Tool returns success.
4. Use pull_request_review_write { method: "submit_pending" }. Review submits without the comment.
5. Verify on the PR — the comment is missing.

Workaround today: use subjectType: "FILE" for file-level comments, or post a top-level issue comment with a permalink. Both lose the inline-thread experience.

Related but distinct: #1748 (fork-PR auth scope) — same symptom (comment doesn't post) but a different root cause.