Inspect hosted assets against build manifests

docs/integrations/gitea.md

@@ -28,6 +28,24 @@ 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.
 
+For a binary-producing release, the client can build a deterministic
+`SHA256SUMS` file from the declared artifact names and SHA-256 digests. Entries
+are sorted by filename and use the standard two-space separator. A source-only
+release produces no manifest.
+
+Asset inspection lists the release attachments, streams each declared existing
+file, and compares its SHA-256 digest. It reports each asset as matching,
+missing, conflicting, or unverifiable. Same-name attachments with different
+bytes are conflicts even when their reported size matches. An existing
+`SHA256SUMS` must exactly match the complete expected manifest; a subset or
+different manifest is a conflict. An unreadable attachment is unverifiable,
+not missing. Unrelated attachments are returned separately and are preserved.
+
+Attachment downloads and same-origin redirects carry authorization only when
+their scheme, host, and port match the configured Gitea service. Cross-origin
+URLs and redirects are left unrequested and reported as unverifiable. Inspection
+uses GET requests only; uploads are a later delivery operation.
+
 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.
+payloads, authorization, streaming comparisons, manifest handling, and failure
+handling. They do not contact a live Gitea service or use real credentials.