gitea forge bundle: name the parent the forge used, match protection rules as the forge does, bound a commit's size and a search's time (issue 539)

The forge's contents and diffpatch endpoints take a branch, never a commit to
build on, so the parent is read from the commit the forge made, and a branch
that moved under the commit is said. Blobs are read at the commit read first,
not at the branch name. Protection rules match as Gitea 1.27 matches them
([...], {a,b}, escapes, a plain name in any case), in the Go bundle and in
guard.ts alike. One commit carries at most 4 MiB per file or patch and 16 MiB
together; code search stops at its deadline and says so. The HTTP client the
two Go bundles copied is one package, internal/forgehttp.

modules/gitea/README.md

@@ -45,28 +45,38 @@ base64-encoded. The Go bundle `cmd/forge` serves the commit, and the reads an ag
 | `gitea_search_code` | r | the lines of a ref's text files matching a literal string or a regular expression, optionally under a path |
 
 **Where a commit may go** is the rule `gitea_api` already holds for a file written (novox/hq ADR 0266):
-never the repository's default branch, never a branch a protection rule names (a glob rule covers by the same
-matcher as `guard.ts`). The rules are read before anything is sent; rules that cannot be read refuse the
+never the repository's default branch, never a branch a protection rule names. A rule covers a branch as the
+forge itself decides it (Gitea 1.27, novox/hq issue 539): a plain name covers that branch in any case; a glob
+(`*`, `**`, `?`, `[abc]`, `[!abc]`, `{a,b}`, `\` escaping) covers case-sensitively with `/` as separator; a glob
+the forge cannot compile covers its own text. `cmd/forge/rules.go` and `guard.ts` hold this one rule. The rules are read before anything is sent; rules that cannot be read refuse the
 commit. Nothing about merging changes: a merge still needs an independent review at the head and both
 required checks green, through `gitea_merge_pull_request`.
 
 **How the commit is made.** `files` become one call to the forge's multi-file contents endpoint: a path the
 ref holds is updated, one it does not is created, and an update or delete carries the blob read just
-before, so a file someone changed meanwhile is refused by the forge rather than overwritten. A `patch` goes
-to the forge's diff endpoint, which applies it; for a small change to a large file this is far shorter than
-the file. Either way the commit is the forge's own, made as the forge's admin account, so its sha is not the
+before, so a file someone changed meanwhile is refused by the forge rather than overwritten. The blobs are read at
+the commit the branch (or, for a new branch, its base) was read at, never at its name. A `patch` goes to the
+forge's diff endpoint, which applies it; for a small change to a large file this is far shorter than the
+file. Neither endpoint takes a commit to build on, only a branch (Gitea 1.27), so the parent answered is the
+one the forge says it made the commit on; when the branch moved between the read and the commit, the answer
+says so. One commit carries at most 200 files, 4 MiB per file and 16 MiB together, or a patch of 4 MiB. Either way the commit is the forge's own, made as the forge's admin account, so its sha is not the
 local commit's: the merge check judges the head on the forge. After the write the branch is read back, and a
 branch not at the commit the forge named is a failure, never a success.
 
 **Code search** has no endpoint on the forge, so the ref's archive (`/archive/{ref}.tar.gz`, at most 64 MiB)
 is read once and searched in memory; a binary file is passed over, a file over 4 MiB is named under
-`skipped`, and at most `max` matches (default 100) are answered, with `truncated` when more were found.
+`skipped`, and at most `max` matches (default 100) are answered, with `truncated` when more were found. A
+search that reaches the call's deadline stops there and answers what it found, with `stopped_at_deadline`.
 
-It reaches the forge as the npm-registry bundle does (below), and one tool call takes at most 50 seconds.
+It reaches the forge through the same HTTP client as the npm-registry bundle (`internal/forgehttp`), and one
+tool call takes at most 50 seconds.
 `go test ./cmd/forge` runs it against a fake forge: the files of one commit created, updated and deleted on
 a new branch from its base; an existing branch committed on; the default branch, a protected branch and
 unreadable rules refused before anything is sent; a patch sent to the forge; a branch read back at another
-commit failing; every malformed ask refused; and each read summarised.
+commit failing; a branch or base that moved under the commit said, with the parent the forge used; a file
+changed under the commit refused; a commit over its size limits refused; protection globs matched as the
+forge matches them; a code search stopped at its deadline; every malformed ask refused; and each read
+summarised.
 
 ## The package registry's retention (novox/hq ADR 0251 §4, to-be 51)