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-files/README.md

@@ -8,7 +8,7 @@ This skill handles file-domain operations within the Gitea integration suite: re
 
 ## Usage
 
-```
+```text
 /gitea-files
 ```
 

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

@@ -24,7 +24,7 @@ allowed-tools: mcp__gitea__get_file_contents mcp__gitea__get_dir_contents mcp__g
 
 - **A 404 may mean an under-scoped token, not a missing path.** Every tool here gates on `write:repository`, and Gitea masks insufficient scope as 404. Check scopes first.
 - **Reads take `ref`, writes take `branch_name`.** One concept, two parameter names — chaining a read into a write drops the branch if you carry the wrong key.
-- **`content` is base64 both ways.** Encode before a write, decode after a read; `withLines: true` returns numbered lines.
+- **`content` is base64 both ways.** Encode before a write, decode after a read.
 
 ## Inputs
 
@@ -32,14 +32,12 @@ allowed-tools: mcp__gitea__get_file_contents mcp__gitea__get_dir_contents mcp__g
 
 ## Dispatch
 
+Read the reference for the row you land on before making the call.
+
 | Condition | Flow | Reference |
 |---|---|---|
-| Read one file, list one directory level, or walk the repository tree | Read | `references/reading.md` |
-| Create, update, or delete a file | Write | `references/writing.md` |
-
-If the request only inspects repository contents, read `references/reading.md` — it carries the three read tools, their pagination behaviour, and why neither a directory listing nor a tree entry supplies the SHA a write needs.
-
-If the request creates, updates or deletes a file, read `references/writing.md` — it carries the SHA-first sequence every update and delete depends on, the worked multi-call sequence, and how to triage a write that fails.
+| Read one file, list one directory level, or walk the repository tree | Read | `references/reading.md` — the three read tools, their pagination behaviour, and why neither a directory listing nor a tree entry supplies the SHA a write needs |
+| Create, update, or delete a file | Write | `references/writing.md` — the SHA-first sequence every update and delete depends on, the worked multi-call sequence, and how to triage a write that fails |
 
 A request that reads and then writes runs both flows in that order: fetch the file first, then write with the SHA that call returned.
 

plugins/gitea/skills/gitea-files/references/writing.md

@@ -29,15 +29,17 @@ commit lands on it in one call, replacing a separate branch-creation step.
 
 ## Delete a file
 
-Same SHA-first pattern, with no create-style fallback — `delete_file` without `sha` returns
-HTTP 422.
+Same SHA-first pattern, with no create-style fallback. `sha` is schema-**required** on
+`delete_file`, unlike `create_or_update_file` where omitting it means *create* — so an omitted `sha`
+is rejected client-side by input validation and the call never reaches Gitea. The HTTP 422 that is
+actually reachable here is the stale-`sha` case.
 
 1. `get_file_contents(owner, repo, ref: <branch>, path)` → read the top-level `sha`.
 2. `delete_file(owner, repo, path, message, branch_name, sha: <that value>)`.
 
 ## Worked sequence — new file on a new branch, then a PR
 
-```
+```text
 1. create_or_update_file
      owner, repo
      path: "docs/example.md"
@@ -58,9 +60,10 @@ when the write replaces an existing one.
 | Symptom | Cause | Action |
 |---|---|---|
 | HTTP 409 | `sha` omitted on a path that already exists | Fetch the current SHA, retry as an update |
-| HTTP 422 | `sha` missing or stale | Re-fetch the SHA immediately before the write |
+| HTTP 422 | Stale `sha` — the file changed between the read and the write | Re-fetch the SHA immediately before the write |
 | 403 or 422 with no SHA explanation | Branch protection requires signed commits | Stop and report |
 | HTTP 413 | Reverse-proxy body limit in front of Gitea | Report; retrying cannot fix it |
+| Client-side input-validation error naming `sha` | `sha` omitted on `delete_file`, where it is schema-required | Fetch the current SHA and retry — nothing was sent to Gitea |
 | HTTP 404 | Wrong path, or a token without `write:repository` | Verify the path, then the token's scopes |
 
 **Signed commits.** These writes create commits server-side from a bare API token with no 2FA or