feat: reach the rest of Gitea with kettle api, and drop tea

The plugin required `tea`, Gitea's own CLI, for everything that is not an
issue: releases, pull requests, milestones, branches, actions, webhooks. That
put a second binary, a second set of logins nothing here could see, and 400
lines documenting somebody else's flags outside anything this repository can
test. One command over the transport that already existed removes all three.

Transport: `post` — the hand-rolled request the SDK cannot express, written for
the dependency endpoint — is generalized to an exported `Do`, and `post` is
three lines on top of it. Same http.Client, so the same RoundTripper files the
body under .kettle/payload/, the same `token …` header authenticates it, and a
non-2xx is the same *APIError. It does not paginate, does not reformat the
answer, and names no domain concept, so the layering test is untouched.

The endpoint rule is `tea api`'s, so an endpoint table written for that tool
still works — with one restriction it did not have: a full URL must be on this
instance. Every request carries the project's token in a header, and a URL on
another host would hand the token to whatever was typed.

Command: `kettle api <endpoint>` in a new `api` group, so the generator writes
plugins/kettle/skills/api/SKILL.md — group, directory and /kettle:api are one
word. No --repo and no --login, for the reason no sync command has them: a
cross-repository address is an address, and another instance is KETTLE_URL.
`-X DELETE` needs `--yes`; a flag typed on purpose is an operator's decision.

Scopes: a token minted for issues carries write:issue and answers 403 on the
first request outside issues, naming no scope. Gitea cannot be asked what a
token may do — its own token listing needs a password — so `auth add --scopes`
records it, `auth list` and `config` show it, and a 403 says which category it
is likely to be. Documentation only; nothing is checked against it.

skills/use — the tea reference, 239 lines of it — becomes skills/api: what to
ask for, which endpoints paginate, and how to write a body. Every mention of
`tea` as a requirement is gone from the manifests, the READMEs, the runner and
the four other skills; what survives is the back-compat with the old plugin,
which is a decision and not a debt.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

cli/internal/config/AGENTS.md

@@ -13,9 +13,19 @@ the tree that imports yaml.
 <project>/.kettle/config.yaml     login: noodles          a NAME, never a token
                                   repo:  owner/name
 
-~/.config/kettle/logins.yaml      logins: [{name, url, user, token}]   mode 0600
+~/.config/kettle/logins.yaml      logins: [{name, url, user, scopes, token}]
+                                                                      mode 0600
 ```
 
+`user` and `scopes` are **documentation and nothing else** — nothing is checked
+against either, and no request is refused because of one. `scopes` is what the
+token was minted with, as Gitea spells it (`write:issue`, `write:repository`),
+and it is written down because the instance will not answer the question:
+`GET /user/tokens` needs basic auth rather than token auth, so a token cannot be
+asked what it may do. What it buys is a 403 that can be read — `kettle auth list`
+and `kettle config` show what was recorded, and an empty list means "nobody wrote
+it down", never "none".
+
 **A token in a file inside a working tree ends up in a commit.** Not always, not
 immediately, and not by anyone careless — but a project config is exactly the file
 somebody eventually decides to share, and a secret that has ever been pushed has to
@@ -84,6 +94,15 @@ Not a silent drop. An older binary reading a newer config would otherwise delete
 setting it did not recognize the next time it wrote the file — which is a data-loss
 bug that only shows up on the machine running the older build.
 
+**The price is that a field added here is a one-way door for the file that holds
+it.** `scopes:` was the first one to prove it: a login file written by a binary
+that has the field cannot be read by one that does not — the older build stops
+with "unknown field" rather than dropping the line. That is acceptable for
+`logins.yaml`, which is machine-local and whose reader is the one binary the
+operator upgrades; it would **not** be acceptable for `config.yaml`, which is
+committed and read by whatever version each machine happens to have. Adding a
+field to the project file means answering that first, out loud, here.
+
 ## What does not belong here
 
 A request, a store path, an issue. This package reads and writes two files and