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

Description 835 -> 214 chars, body 669 -> 426 words, Gotchas 8 entries/63% of
body -> 3/20.4%. Clears the description FAIL, all three Vale CompositionNote
errors and both Gotchas suggestions. 63% was the worst Gotchas ratio in the
corpus.

Cut the composition sentence to README -- it changes no routing decision and an
agent picks this skill because the user asked about labels, not because two
other skills call it. Cut the capability enumeration; 'list, create, edit,
delete' decompose 'reading or writing' and add no trigger.

Boundary clauses are now one arrow per target. The resolver extracts only the
first name per arrow clause, so the previous '-> gitea-issues / gitea-prs' left
gitea-prs neither dangling nor checked while validate.sh reported 1 of 1. Now
2 of 2.

Makes org-scoped label resolution executable. The org label pool was reachable
in principle -- four *_org_label* methods, and a claim to own name-to-ID
resolution -- but list_org_labels takes org, and Step 1 derived only owner and
repo, so both resolution procedures stalled at the fallback. Fixed once at the
identity step rather than per-procedure. get_user_orgs is outside allowed-tools,
so the failing call is the discriminator: a failure means the owner is a user
account with no org pool, which is an answer, not an error.

Corrects a Gotcha that was false for create_repo_label/create_org_label and
collided with the literal tool name label_write. Same false claim removed from
README.

Refs #99

plugins/gitea/.apm/skills/gitea-labels-milestones/references/label-inference.md

@@ -57,7 +57,11 @@ scope applied at once.
 1. Read the conversation context (issue/PR title, body, or the triggering discussion) for the
    signals above.
 2. Call `label_read method: "list_repo_labels"` (see `references/labels.md`) to get the current
-   label set with IDs — inference must never guess an ID, only a name, then resolve it.
+   label set with IDs — inference must never guess an ID, only a name, then resolve it. Because
+   `exclusive` is an org-labels-only flag, this taxonomy plausibly lives at org scope too: for any
+   inferred name absent from the repo pool, also call `label_read method: "list_org_labels"` with
+   `org` set to the repo's `owner` before treating it as unresolved. A failure there means the owner
+   is a user account, not an organisation, so no org pool exists and the name is genuinely absent.
 3. Match inferred label names against the resolved list (case-insensitive). If a scope group
    already has a different label applied on the target and a new one is inferred for that same
    scope, plan to replace rather than add (see above).