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-labels-milestones/references/label-inference.md

@@ -14,9 +14,13 @@ asks to label something without naming exact labels.
 
 ## Scoped labels are mutually exclusive — replace, don't stack
 
-Each of `Kind/*`, `Priority/*`, `Status/*` is a Gitea scoped-label group (the `/` delimiter plus
-`exclusive: true` on the label). Applying a new label within a scope is expected to replace any
-existing label in that same scope on the target issue/PR, not add alongside it. When inference
+Each of `Kind/*`, `Priority/*`, `Status/*` is treated as a scoped-label group by convention (the `/`
+delimiter naming pattern). Gitea's `exclusive` flag — the mechanism that would let the server itself
+enforce one-label-per-scope — is documented as an org-labels-only setting, and the repo-level
+`label_write` methods used here don't accept it at all. So exclusivity within these scopes is a
+convention this skill enforces client-side, not something the server guarantees: applying a new
+label within a scope is expected to replace any existing label in that same scope on the target
+issue/PR, not add alongside it. When inference
 selects a `Priority/High` label and the issue already carries `Priority/Medium`, the write should
 result in only `Priority/High` remaining — use `replace_labels` scoped to that group's labels, or at
 minimum remove the superseded label before adding the new one. Never leave two labels from the same