refactor(gitea-files): retrofit to the ADR-0020 context contract

Description 787 -> 263 chars, body 922 -> 302 words, Gotchas 9 entries/69% of
body -> 3/24.8%. Clears both size FAILs and both Gotchas suggestions.

Deleted the second trigger register outright -- ~300 chars re-quoting the same
six verbs as user phrasings, which ADR-0020 names this skill for specifically.

Split the body on the read/write boundary: one invocation cannot both read and
write, so a dispatch table is mandatory. Six operations collapse into two flow
files rather than six -- create/update/delete share one tool pair and one
SHA-first lifecycle whose preamble would otherwise be triplicated, and the three
read tools share ref selection plus a 'neither listing is a SHA source'
comparison that only exists between them.

references/examples.md removed; all eight of its content blocks and all nine
named parameters carry into references/writing.md, verified against git HEAD.
Two deltas are corrections: the repo tree is now ruled out as a SHA source, and
reusing a SHA captured earlier in the conversation is now forbidden.

Four Gotchas relocated to the flow file that needs them; two promoted to gates
(SHA-as-concurrency-token opens writing.md; owner/repo became ## Inputs).

Refs #99

plugins/gitea/.apm/skills/gitea-files/references/reading.md

@@ -0,0 +1,46 @@
+---
+source_keys:
+  - gitea-mcp-repo
+  - gitea-mcp-slim-go
+---
+
+# Reading files, directories and trees
+
+All three read calls select what to read with `ref` — a branch name, tag, or commit SHA. On
+`get_repository_tree` the same value goes in `tree_sha` despite the name.
+
+## Single file
+
+`get_file_contents(owner, repo, ref, path)`.
+
+The response carries the file's `sha` at the **top level**, not nested under `content`. That field
+is the write-ready SHA, so capture it whenever a write may follow. Content comes back
+base64-encoded — decode it. Pass `withLines: true` only when you need numbered lines to quote
+specific lines back to the user; omit it for a normal content fetch.
+
+## One directory level
+
+`get_dir_contents(owner, repo, ref, path)` returns the immediate entries only — name, path, type,
+size. No recursion, no content, no `sha`.
+
+## Whole repository tree
+
+`get_repository_tree(owner, repo, tree_sha, recursive)`. Set `recursive: true` to walk
+subdirectories in one call.
+
+The response sets `truncated: true` when one page does not hold every entry. Page through with
+`page`/`per_page` (defaults `1` and `30`) until a page returns fewer entries than `per_page`.
+
+## Neither listing is a SHA source for a write
+
+`get_dir_contents` entries carry no `sha` at all. `get_repository_tree` entries do carry a blob or
+tree hash, but reaching it costs an extra round trip and returns no content. `get_file_contents` is
+the canonical path for a write's SHA: one call returns the decoded content and the write-ready
+`sha` together.
+
+## A 404 that is really a 403
+
+These reads gate on `write:repository`, not on read access alone, and some Gitea endpoints answer
+an under-scoped token with 404 instead of 403 so they do not leak whether the resource exists. A
+404 on a path you are confident about is a scope problem until proven otherwise — check the token's
+configured scopes before concluding the file or directory does not exist.