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/SKILL.md

@@ -21,9 +21,9 @@ metadata:
     - gitea-mcp-slim-go
     - context7-websites-gitea
     - context7-gitea-tea-cli
-  version: "0.1.0"
+  version: "0.1.1"
 
-allowed-tools: mcp__gitea__label_read mcp__gitea__label_write mcp__gitea__milestone_read mcp__gitea__milestone_write
+allowed-tools: Bash mcp__gitea__label_read mcp__gitea__label_write mcp__gitea__milestone_read mcp__gitea__milestone_write
 ---
 
 ## Gotchas
@@ -33,11 +33,21 @@ allowed-tools: mcp__gitea__label_read mcp__gitea__label_write mcp__gitea__milest
 - **Milestone representation differs between issues and PRs.** `issue_read` returns `milestone: {id, title}` — an object. `pull_request_read` returns `milestone: "title string"` — title only, no ID. You cannot recover a milestone ID from a PR response directly; call `milestone_read method: "list"` and match by title instead.
 - **Repo labels and org labels are separate pools, never mixed in one call.** `label_read`/`label_write` take either `owner`+`repo` (repo-scoped methods) or `org` (org-scoped methods) — passing both or neither for a given method is a caller error, not something the schema enforces for you. Repo and org labels can both apply to the same issue, but you list/create/edit them through different method values.
 - **`milestone_write` accepts `"update"` and `"edit"` as the same operation.** Both method values map to the identical update call. Prefer `"update"` for consistency with `issue_write`/`pull_request_write`.
-- **A `/` in a label name plus `exclusive: true` means mutual exclusivity, not just a naming convention.** This repo's `Kind/*`, `Priority/*`, `Status/*` labels follow Gitea's native scoped-label feature: applying a new label within a scope (e.g. `Priority/High`) is expected to replace any existing label in that same scope, not add alongside it. Label inference (see `references/label-inference.md`) must respect this — replace, don't stack.
+- **`exclusive` is documented as an org-labels-only flag — it isn't what enforces exclusivity here.** Gitea's docs scope the settable/server-enforced `exclusive` flag to org labels only, and the live `label_write` schema for `create_repo_label`/`edit_repo_label` doesn't document accepting it at all. This repo's `Kind/*`, `Priority/*`, `Status/*` groups still behave as one-label-per-scope, but that's a manually-enforced convention this skill implements client-side, not a guaranteed server behavior for repo labels: applying a new label within a scope (e.g. `Priority/High`) must replace any existing label in that same scope, not add alongside it, and nothing on the server enforces that for you. Label inference (see `references/label-inference.md`) must respect this — replace, don't stack.
 - **Pagination is manual on every list call.** `label_read` and `milestone_read` both default to `per_page: 30`. Iterate `page: 1, 2, ...` until the result count is less than `per_page` — there is no cursor or auto-pagination.
 - **Schema requiredness differs between the two tool families.** `milestone_read`/`milestone_write` have `owner` and `repo` as hard-required parameters (the call fails validation without them). `label_read`/`label_write` only hard-require `method` — `owner`/`repo`/`org` are functionally required per method but not schema-enforced, so passing none produces a runtime error from Gitea, not a client-side validation error.
 
-## Dispatch
+## Step 1 — Resolve owner and repo
+
+Before any tool call, extract `owner` and `repo` from the git remote (skip this if an orchestrating caller already passed them in):
+
+```bash
+git remote get-url origin
+```
+
+If origin is not set or the URL is not a Gitea URL, stop and report: "No Gitea remote found — set origin to your Gitea instance URL."
+
+## Step 2 — Dispatch
 
 | Task | Tool | method |
 |---|---|---|