POST /api/v1/repos/{owner}/{repo}/merge-upstream kept importing commits
from the parent repository even after the parent was switched from public
to private, leaking commits a fork owner could no longer access directly.
Require the doer to still have read access to the base repo's code before
syncing, and map the permission error to 403 (API) / not-found (web).
Assisted-by: Claude:claude-opus-4-8
1 Move `IsRepositoryModelOrDirExist` and `CheckCreateRepository` to
service layer
2 Use `gitrepo.Pushxxx` instead of `git.Push` when possible
3 use `gitrepo.Clonexxx` instead of `gitrepo.Clone` when possible
The merge-upstream route was so far performing any kind of merge, even
those that would create merge commits and thus make your branch diverge
from upstream, requiring manual intervention via the git cli to undo the
damage.
With the new optional parameter ff_only, we can instruct gitea to error
out, if a non-fast-forward merge would be performed.
Fix#33271
Suppose there is a `branch-a` in fork repo:
1. if `branch-a` exists in base repo: try to sync `base:branch-a` to `fork:branch-a`
2. if `branch-a` doesn't exist in base repo: try to sync `base:main` to `fork:branch-a`
Nicolas