Add Codeberg support to the Web UI

[abcdvvvv]

Summary

This PR adds Web UI support for registering packages hosted on Codeberg. It depends on the Forgejo support added in JuliaWeb/GitForge.jl#55.

With this change, Registrator can authenticate with Codeberg, inspect a package repository hosted there, and submit the registration request against the configured registry through the usual Web UI flow.

Scope

This PR is intentionally limited to the Web UI path.

It does not add comment-triggered registration on Codeberg. The final registry PR workflow is unchanged as well: for General, Registrator still opens the registration PR on GitHub.

What Changed

• added codeberg as a built-in Web UI provider
• wired ForgejoAPI into the provider, auth, and callback flow
• extended the existing built-in "already authenticated" shortcut in routes/auth.jl to include Codeberg
• added Forgejo-specific handling in gitutils.jl for authorization checks, project file loading, commit lookup, clone URL construction, web URL rendering, and tag mismatch checks
• extended the Web UI tests to cover the Codeberg / Forgejo path
• updated the Web UI documentation and sample config to include Codeberg

Why The OAuth Changes Are Needed

Live testing against Codeberg also exposed two places where the existing Web UI assumptions did not hold.

First, the callback token exchange in src/webui/routes/callback.jl could not complete successfully with the previous implementation. Registrator was sending the OAuth token exchange parameters in the POST query string. In live testing, Codeberg responded with 400 Bad Request, unsupported_grant_type, and the message Only refresh_token or authorization_code grant type is supported, even though the request still included grant_type=authorization_code. In practice, moving those parameters into an application/x-www-form-urlencoded POST body fixed the callback flow. This is therefore a functional fix, not a stylistic cleanup.

Second, even after OAuth login succeeded, the returned Codeberg OAuth token still could not read repository metadata through GET /repos/{owner}/{repo} in the way the existing Web UI authorization path expected. In practice, the user could authenticate successfully, but the subsequent repo refresh step still failed with a read:repository error.

That behavior is consistent with the current Forgejo documentation, which explicitly notes that OAuth2 scopes are not yet implemented and distinguishes OAuth2 tokens from scoped personal access tokens:

• https://forgejo.org/docs/latest/user/oauth2-provider/
• https://forgejo.org/docs/latest/user/token-scope/

So the problem here was not that Registrator requested the wrong scope. The issue was that the previous Web UI flow assumed stronger repository-read semantics from a Forgejo OAuth token than the platform currently guarantees.

The Forgejo authorization path is therefore adjusted so the OAuth token is still used to identify the logged-in user, while repository lookup and authorization fallback can continue using the configured server-side Codeberg client when that user-token repo refresh fails. If the user-token refresh succeeds, Registrator still trusts the per-user permissions.push fast path. If it fails, Registrator falls back to collaborator, owner, and membership checks instead of rejecting the registration immediately.

This does not change the high-level behavior for the existing built-in providers. Registrator still performs the same callback and token exchange flow against each provider's configured token_url; the Codeberg-specific change is that the token exchange parameters are now sent in the request body, and the Forgejo authorization path is able to fall back cleanly when user-token repo refresh is unavailable.

Validation

• julia --project=. test/runtests.jl passes (120 / 120)
• the Web UI provider and gitutils tests now cover the Codeberg / Forgejo path
• the Codeberg Web UI flow was validated end-to-end against a test registry:
  • Codeberg OAuth login succeeded
  • the Forgejo authorization fallback handled the OAuth token not having read:repository
  • the registration request reached RegService
  • Registrator created and pushed a registry branch
  • Registrator opened a registry pull request successfully: New package: DependencyAtlas v0.1.0 abcdvvvv/TestRegistry#1
• documentation and sample config were updated to match the implementation

Related

• Depends on Add Forgejo support with live Codeberg validation JuliaWeb/GitForge.jl#55
• Refs [Feature request] Codeberg support #430
• Refs [Feature request] Codeberg support JuliaWeb/GitForge.jl#49

Generated with Codex assistance.

[abcdvvvv]

The current CI failure is expected for now because this PR depends on JuliaWeb/GitForge.jl#55.

This branch now imports GitForge.Forgejo, but CI still resolves the latest released GitForge version, which does not yet include that module.

Locally, I tested this branch with Registrator.jl resolved against the Forgejo-enabled GitForge.jl worktree from JuliaWeb/GitForge.jl#55, and the Codeberg Web UI flow was validated end-to-end (abcdvvvv/TestRegistry#1).