fix(gitea): make gitea-releases executable and correct misleading domain claims

gitea-releases was the weakest skill in the plugin: no allowed-tools, no
owner/repo resolution, and a checkbox list where a dispatch table belongs, so
an agent reaching it had to guess both its permissions and its inputs. The
id-vs-tag_name trap — deleting by tag name where the API wants the numeric id —
is restored as an explicit Gotcha because it destroys the wrong release
silently.

Elsewhere the `exclusive` flag was documented on the wrong side of the
read/write split, and label data from one instance was presented as though it
were universal, which invites an agent to assume a taxonomy that does not
exist on the target repo. rename_branch was missing from the branch surface.
Reference prose and fences are cleaned up in passing.

plugins/gitea/skills/gitea-branches/references/branches.md

@@ -7,10 +7,11 @@ source_keys:
 
 # Branch operations
 
-Call signatures below were verified live against the deployed `gitea-mcp` server via `ToolSearch`
-at authoring time, not copied from research docs — this is deliberate: research docs are generated
-from source code at a point in time and can drift from the server actually deployed. Re-verify
-against the live schema if these tools appear to behave differently than documented here.
+Call signatures below were verified live against the deployed `gitea-mcp` server via `ToolSearch`,
+not copied from research docs — this is deliberate: research docs are generated from source code at
+a point in time and can drift from the server actually deployed. **Last verified against gitea-mcp
+v1.7.0**, as reported by `get_gitea_mcp_server_version`. Re-verify against the live schema if the
+deployed version differs or these tools behave differently than documented here.
 
 ## `list_branches`
 
@@ -21,7 +22,7 @@ against the live schema if these tools appear to behave differently than documen
 - `per_page` (number, optional, default: `30`)
 
 **Call:**
-```
+```text
 list_branches owner: <owner> repo: <repo>
 ```
 
@@ -41,7 +42,7 @@ count is less than `per_page`.
   branch server-side (not necessarily your current local checkout)
 
 **Call:**
-```
+```text
 create_branch owner: <owner> repo: <repo> branch: <new-name> old_branch: <source-branch>
 ```
 
@@ -53,6 +54,29 @@ top-level request with no working branch context), omit `old_branch` and let it
 
 A branch name collision returns `409 Conflict`.
 
+## `rename_branch`
+
+**Parameters:**
+- `owner` (string, required)
+- `repo` (string, required)
+- `branch` (string, required) — the branch's current name
+- `new_name` (string, required) — the name to move it to
+
+**Call:**
+```text
+rename_branch owner: <owner> repo: <repo> branch: <current-name> new_name: <new-name>
+```
+
+A rename moves the ref server-side; it is not a delete-plus-create, and no commit history is
+rewritten. What it does to things *pointing at* the old name — open pull requests using it as head or
+base, a branch protection rule matching it, CI config, and tracking branches on every other clone —
+is **not confirmed** by this skill's sources: the deployed tool describes itself only as "Rename an
+existing branch in a repository". Treat a rename of a branch with open PRs or a protection rule as a
+change needing verification afterward (`list_branches`, plus `gitea-prs` for the PR side), and
+confirm with the user first, exactly as for `delete_branch` below. A collision with an existing
+branch name is expected to return `409 Conflict` by analogy with `create_branch`, not separately
+confirmed.
+
 ## `delete_branch`
 
 **Parameters:**
@@ -61,7 +85,7 @@ A branch name collision returns `409 Conflict`.
 - `branch` (string, required)
 
 **Call:**
-```
+```text
 delete_branch owner: <owner> repo: <repo> branch: <name>
 ```
 
@@ -73,9 +97,12 @@ protected, every time, regardless of how the request is phrased.
 
 ## Token scope
 
-All three — `list_branches`, `create_branch`, `delete_branch` — require `write:repository`. Gitea
+`list_branches`, `create_branch` and `delete_branch` all require `write:repository`. Gitea
 gates reads behind write scope for repo-scoped operations, so `list_branches` needs the same scope
 as the write operations, not `write:issue` alone. An earlier version of this doc claimed
 `write:issue` alone was sufficient for `list_branches`, based on empirical testing under a token
 that held both `write:issue` and `write:repository` simultaneously — that test didn't isolate the
 variable, so it couldn't actually establish `write:issue` alone as sufficient.
+
+`rename_branch` is a write on the same repo-scoped surface and is inferred to need `write:repository`
+too — inferred by analogy, not separately confirmed.