feat: add Gitea issue comment list/create MCP tools (#126)

Add gitea_list_issue_comments and gitea_create_issue_comment so
discussion/design workflows can read and post issue comments through
the MCP layer instead of direct API scripts.

- List requires gitea.read; create requires gitea.issue.comment —
  gated separately from the gitea.pr.* review/merge family, fail closed.
- Issue comments never touch PR review endpoints.
- LLM-safe output: comment id/author/timestamps/body only; web links
  appear solely under the GITEA_MCP_REVEAL_ENDPOINTS admin opt-in.
- Create operations are audit-logged (create_issue_comment) and errors
  are redacted before being raised.
- Tests cover list/create success, permission blocks (including PR
  review permissions not granting issue comments), forbidden-overrides,
  empty body, missing issue with redacted error, endpoint separation,
  and reveal opt-in.
- Document issue comments versus PR reviews in
  docs/gitea-execution-profiles.md.

Closes #126

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/gitea-execution-profiles.md

@@ -179,6 +179,30 @@ allowed/forbidden membership check):
   therefore never silently widen permissions.
 - An empty or missing `allowed_operations` list denies everything.
 
+## Issue comments versus PR reviews (#126)
+
+Issue discussion comments and PR reviews are different capabilities and are
+gated by different operations:
+
+- **Issue comments** (`gitea_list_issue_comments`, `gitea_create_issue_comment`)
+  post to and read from an issue's discussion thread
+  (`/issues/{n}/comments`). Listing requires `gitea.read`; creating requires
+  `gitea.issue.comment`. They never submit review verdicts.
+- **PR reviews** (`gitea_review_pr`, `gitea_submit_pr_review`) submit
+  approve/request-changes/comment verdicts on pull requests
+  (`/pulls/{n}/reviews`) and are gated by the `gitea.pr.*` family
+  (`gitea.pr.review`, `gitea.pr.approve`, `gitea.pr.request_changes`,
+  `gitea.pr.comment`).
+
+A profile holding the full PR review/merge set still cannot post issue
+discussion comments unless it also allows `gitea.issue.comment`, and vice
+versa — neither family implies the other. Both comment tools require an
+explicit issue number; the target repo comes only from the standard
+remote/org/repo arguments. Create operations are audit-logged
+(`create_issue_comment`) when `GITEA_AUDIT_LOG` is configured, errors are
+redacted, and normal output contains no endpoint URLs
+(`GITEA_MCP_REVEAL_ENDPOINTS=1` is the local admin opt-in for web links).
+
 ## Identity and fail-closed rules
 
 Before **any** mutating action, a workflow must know both: