[FEATURE] Support Forgejo and Gitea push webhooks for docs rendering

[CybotTM]

Fixes #304

Forgejo and Gitea send X-GitHub-Event as a compatibility header alongside their own, so their pushes were handled as Github pushes and the composer.json was looked up on raw.githubusercontent.com. For the repository in the issue that is a 404 where git.codemacher.de/…/raw/branch/main/composer.json returns 200.

This routes their push events before the Github check and resolves the composer.json against repository.html_url, so instances on any domain work.

Two things touch the shared Github path, please look at these: a body that is valid json but not an object now returns 422 instead of raising a TypeError (500), and a truncated commit list now renders instead of being dropped as "no documentation changes". Both are explained below.

t3g:test (192 tests), t3g:phpstan, t3g:cgl, npm ci and npm run build pass. The functional suite needs the private t3g/lib-test-helper and could not be run here.

Documentation follow-up, held as a draft until this is released: TYPO3-Documentation/TYPO3CMS-Guide-HowToDocument#526

---

Details — verification against a real instance, the two behaviour changes, known limitations, and how to reproduce

Verified against a real Forgejo instance

Not only against the source: I ran Forgejo 12.0.4 locally, pointed a webhook at a recorder and replayed the captured deliveries through the actual WebHookService.

push	what the delivery contains
branch with a Documentation/ change	X-Forgejo-Event, X-GitHub-Event, X-Gitea-Event, X-Gogs-Event all push
tag	ref: refs/tags/…, commits: []
tag deletion	regular push, after = 40 zeros, no deleted property
branch deletion	no push event at all, only a delete event
20 commits	commits: 15, total_commits: 20

Replaying those captures against develop shows what users get today: every url points at raw.githubusercontent.com, the tag deletion is accepted as a render trigger, and the 20-commit push is dropped. With this branch the urls point at the instance and resolve (/raw/branch/main/composer.json and /raw/tag/2.0.0/composer.json both 200). The fixtures here were checked field by field against those real payloads — that is what added the missing head_commit and corrected compare_url on the deleted-tag fixture.

To reproduce, no Forgejo account needed:

docker run -d --name fj --network host \
  -e FORGEJO__security__INSTALL_LOCK=true \
  -e FORGEJO__server__ROOT_URL=http://localhost:3000/ \
  -e FORGEJO__webhook__ALLOWED_HOST_LIST='*' \
  -e FORGEJO__database__DB_TYPE=sqlite3 codeberg.org/forgejo/forgejo:12
docker exec -u git fj forgejo admin user create --username tester \
  --password 'TestPass123!' --email t@example.com --admin --must-change-password=false

Then create a repository, point a push webhook at any request bin, and push. I deliberately did not add this as an automated test: the project has no container in its test path at all — the functional suite runs against file-based SQLite and the CI workflow has no services: section — so adding one for a single provider would be infrastructure out of proportion to the change.

The two changes on the shared Github path

Non-object json body. The shared payload handling is typed, so without a guard a body like 123 raises a TypeError and answers 500 where it used to answer 422. It is now rejected as an unsupported request. On develop this was InvalidWebHookPayloadException / HOOK_INVALID_PAYLOAD; it is now UnsupportedWebHookRequestException / UNSUPPORTED_HOOK, same http status. Say the word if you would rather keep the old classification.

Truncated commit list. Senders cap the list — Forgejo at 15, Gitea at 5 — while total_commits keeps the real number, so a documentation change in a dropped commit would never render and could not be recovered. A truncated list therefore no longer counts as "nothing to render". Github payloads carry no total_commits and are unaffected.

I verified every other existing path is byte-identical to develop by running a payload matrix (Github branch/tag/rst/form-encoded/ping/broken-json/malformed-commits, GitLab, both Bitbucket variants) against both revisions and diffing.

Known limitations, so they are not mistaken for oversights

Deleting a branch on Forgejo sends no push event, only a delete event, which falls through to UNSUPPORTED_HOOK (422) rather than the BRANCH_DELETED (404) a Github deletion produces.

RepositoryUrlUtility still matches only the three cloud hosts, so RenderOtherBranchesFromNewDocsCommand cannot resolve a composer.json for a Forgejo repository. The webhook path is unaffected.

SERVICE_NAMES is deliberately not extended: it only feeds the manual wizard's dropdown, and that path resolves urls via RepositoryUrlUtility — a Forgejo entry there would build a Bitbucket-shaped url.

Merging this does not by itself make the reporter's instance work: assertUrlToComposerFileIsSafe() still requires an admin to approve the domain.