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

先閱讀 add_comment_to_pending_review 和 pull_request_review_write 入口點，然後使用 diff 外部的評論重現 issue 中描述的待處理 review 工作流程。追蹤 submit_pending 如何處理這些評論，以及 GraphQL addPullRequestReviewThread mutation 如何接受 path 和 line。完成標準是：錯誤被呈現，或任意檔案行的評論能夠以 inline 形式保留，同時現有的檔案層級 workaround 仍然可用。

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.