Add Gitea release page transport

docs/integrations/gitea.md

@@ -0,0 +1,33 @@
+# Gitea release pages
+
+ReleaseKit's internal Gitea client verifies a hosted source tag and finds or
+creates its stable release page. The public delivery facade and CLI workflow
+are planned separately; this integration guide describes the implemented
+internal operation.
+
+The caller supplies the Gitea base URL, owner, repository name, and token
+explicitly. The client does not read ambient credentials. The token is sent in
+the `Authorization: token …` request header and is not included in errors or
+results. The base URL must use HTTP or HTTPS and cannot contain URL credentials,
+a query, or a fragment.
+
+For version `vMAJOR.MINOR.PATCH`, the client first reads
+`/api/v1/repos/{owner}/{repo}/tags/{tag}` and requires the hosted tag's commit
+SHA to equal the captured source commit. It then reads
+`/api/v1/repos/{owner}/{repo}/releases/tags/{tag}`. A matching existing page
+must have that tag, the complete committed release note as its body, and stable
+non-draft state. Its existing title is retained. ReleaseKit does not edit a
+conflicting page.
+
+If the page is absent, the client posts to `/api/v1/repos/{owner}/{repo}/releases`
+with the selected tag and commit, the release note's H1 as title, the complete
+note as body, and draft and prerelease disabled. A create conflict, interrupted
+response, or malformed create response triggers one lookup. An exact page found
+there confirms the existing content; a differing page is a conflict. If that
+lookup cannot determine the result after a possibly successful write, the
+client returns an unknown outcome. Other HTTP failures retain their structured
+failure kind and status code.
+
+The integration tests use a local HTTP fixture and assert request paths,
+payloads, authorization, and failure handling. They do not contact a live Gitea
+service or use real credentials.