fix(gitea): correct label-scope and closing-keyword claims in issues/labels skills

A documentation-accuracy audit against plugins/gitea/docs/research/docs/gitea/*.md
found three overclaims/unsupported claims in skill content:

- gitea-labels-milestones: reworded the exclusive-flag gotcha and
  label-inference.md's "scoped labels" section — exclusive is documented as
  org-labels-only (api-reference.md, data-model.md) and unsupported by the
  live create_repo_label/edit_repo_label schema, so repo-level exclusivity
  for Kind/*/Priority/*/Status/* is a client-side convention this skill
  enforces via replace_labels, not a server guarantee.
- gitea-labels-milestones: added a "Step 1 — Resolve owner and repo" section
  (git remote get-url origin) and Bash to allowed-tools, since
  milestone_read/milestone_write and repo-scoped label_read/label_write
  hard-require owner+repo and the skill is documented as directly invokable,
  matching the pattern already in gitea-issues/SKILL.md.
- gitea-issues: softened the claim that Gitea parses Fixes #N/Closes #N in
  commit messages to auto-close issues — no research doc supports this, and
  examples.md states issues are not auto-closed on PR merge. Now notes the
  behavior is plausible but unconfirmed, keeping the issue_read re-check.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VwtxcDXuLZxYzWnT2FaoZU

plugins/gitea/skills/gitea-issues/SKILL.md

@@ -35,7 +35,7 @@ allowed-tools: Bash mcp__gitea__list_issues mcp__gitea__issue_read mcp__gitea__i
 - **`search_issues` does have a working `type` filter** (`"issues"` | `"pulls"`) — unlike `list_issues`. Its `labels` parameter is also shaped differently: a comma-separated string, not an array of names.
 - **Labels are numeric IDs on write, name strings on read.** `issue_write`'s `labels` parameter (used by `add_labels`/`replace_labels`) takes IDs. `list_issues`/`issue_read` return names. Never resolve this yourself — compose `gitea-labels-milestones` (see `references/enrichments.md`) to get IDs.
 - **Milestone on `issue_read` is `{id, title}`** — an object, not a bare string. This skill only ever needs the `id`. (The bare-title-string case only happens on the PR side, which is `gitea-prs`' problem, not this skill's.)
-- **A closing keyword in a commit message can auto-close an issue without any `issue_write` call.** Gitea has no GitHub-style "merge closes issue" event, but it does parse `Fixes #N`/`Closes #N` in commit messages landing on the default branch. After a PR merges (a `gitea-prs` operation), re-check the issue's state here via `issue_read method: "get"` before deciding whether to close it manually — closing an already-closed issue is a harmless no-op, but don't assume a manual close is always needed.
+- **Closing-keyword auto-close behavior is plausible but unconfirmed in our research docs.** Our research docs confirm Gitea does NOT auto-close an issue on a plain PR merge (unlike GitHub) — closing keywords like `Fixes #N`/`Closes #N` in a commit message are not documented one way or the other. After a PR merges (a `gitea-prs` operation), always re-check the issue's state here via `issue_read method: "get"` before deciding whether to close it manually — closing an already-closed issue is a harmless no-op, but don't assume a manual close is always needed.
 - **Pagination is manual.** `list_issues` and `search_issues` return one page at a time. Iterate `page: 1, 2, ...` until the returned count is less than `per_page`.
 - **HTTP 404 may actually mean 403.** Gitea hides permission errors as not-found. If a call 404s unexpectedly, verify the token holds `write:issue` scope (see `references/issues.md`'s Token scope note) before concluding the issue doesn't exist.