Repository migration SSRF via multi-answer DNS allow-list bypass

Affected: Go: code.gitea.io/gitea

### Summary

Gitea's repository migration URL validation can be bypassed when a migration hostname resolves to multiple IP addresses. The validation logic accepts the destination if **any** resolved IP is allowed, even if another resolved IP is loopback, private, or otherwise blocked. The later `git clone` operation resolves the hostname again outside of that validation decision, so it can connect to the internal address.

An authenticated low-privilege user who can create repository migrations can use an attacker-controlled DNS name to make Gitea connect to internal-only Git services and import their contents into a repository controlled by the attacker.

### Details

The issue is in `services/migrations/migrate.go`, in the migration allow/block-list check.

Current logic computes whether any resolved IP is allowed:

```go var ipAllowed bool var ipBlocked bool for _, addr := range addrList { ipAllowed = ipAllowed || allowList.MatchIPAddr(addr) ipBlocked = ipBlocked || blockList.MatchIPAddr(addr) } ```

Then, when an allow-list is active, the host is accepted if the hostname matches or `ipAllowed` is true:

```go if !allowList.IsEmpty() { if !allowList.MatchHostName(hostName) && !ipAllowed { return &git.ErrInvalidCloneAddr{Host: hostName, IsPermissionDenied: true} } } ```

This means a hostname resolving to both:

- an allowed public IP, e.g. `1.2.3.4` - a blocked internal IP, e.g. `127.0.0.1`

passes validation because the public IP sets `ipAllowed =…