fix: add OpenWorldHint to default-on UGC issue/PR/discussion tools

[tiagovilasboas]

Summary

Add an explicit OpenWorldHint: true to the always-on issue, pull request, and discussion tools that return or publish user-generated content, matching the annotation already shipped on granular issue/PR tools.

Why

MCP clients that require a real boolean (the same class of gap as ReadOnlyHint in #2483) cannot treat an omitted OpenWorldHint as the spec default of true. That leaves the default-on UGC path unannotated while feature-flagged granular siblings already declare OpenWorldHint: true.

#1100 postponed a broad OSS rollout because adding the hint to search tools on the remote server was disruptive. This PR is a narrow slice: default-on issue/PR/discussion UGC only. Search tools and closed-world getters are unchanged.

Related: #1100 (postponed broad OSS OpenWorldHint), granular tools on main, stalled broad #1700.

What changed

• issue_read, issue_write, add_issue_comment
• pull_request_read, pull_request_review_write, add_comment_to_pending_review, add_reply_to_pull_request_comment
• get_discussion, get_discussion_comments, discussion_comment_write
• Matching test assertions and __toolsnaps__ updates

MCP impact

• No tool or API changes
• Tool schema or behavior changed
• New tool added

Annotations only. Clients that honor explicit openWorldHint: true can now prompt before fetching or publishing untrusted issue/PR/discussion content. Spec-compliant clients that already default omitted to true see no semantic change.

Prompts tested (tool changes only)

• Annotation-only change; no tool arguments or handler behavior changed
• Covered by existing tool definition tests plus OpenWorldHint assertions

Security / limits

• No security or limits impact
• Auth / permissions considered
• Data exposure, filtering, or token/size limits considered

AppSec: issue/PR/discussion bodies and comments are untrusted UGC. An explicit open-world hint lets permission gates treat that surface as external data instead of a closed, trusted domain.

Tool renaming

• I am renaming tools as part of this PR (e.g. a part of a consolidation effort)
  • I have added the new tool aliases in deprecated_tool_aliases.go
• I am not renaming tools as part of this PR

Lint & tests

• Linted locally with ./script/lint
• Tested locally with ./script/test

Focused pkg/github annotation/toolsnap tests and TestAllToolRegistrationsExplicitlySetReadOnlyHint passed. Full ./script/test / lint status will be reflected in CI.

Docs

• Not needed
• Updated (README / docs / examples)

[tiagovilasboas]

Hi — first-time contributor here. Could a maintainer please approve and run the pending workflows when you have a moment? Thanks!