oras-go: Blind SSRF via unvalidated Link header URL in pagination allows internal network probing

## Summary oras-go's pagination helper `parseLink()` in `registry/remote/utils.go` follows the `Link` response header from a registry without validating the URL's host or scheme. When a malicious registry returns a `Link` header containing an absolute URL pointing to an arbitrary host (e.g., a cloud metadata endpoint), the client makes GET requests to that host from the victim's network. This affects all pagination-based listing operations: Tags, Referrers, and Repositories (catalog). ## Root Cause `parseLink()` at `registry/remote/utils.go:54` calls `resp.Request.URL.Parse(link)` which, for absolute URLs, returns the absolute URL unchanged. The result is passed directly to the next pagination loop iteration where `http.NewRequestWithContext()` creates a GET request to the attacker-specified URL. No host comparison, scheme validation, or IP filtering exists between `parseLink` output and the HTTP request. ## Affected Code Paths - `registry/remote/repository.go:Tags()` calls `parseLink()` for next page URL - `registry/remote/repository.go:Referrers()` calls `parseLink()` for next page URL - `registry/remote/registry.go:Repositories()` calls `parseLink()` for next page URL ## Impact **Blind SSRF from the victim's network.** A malicious registry operator can force any oras-go client that lists tags, referrers, or repositories to issue GET requests to arbitrary internal endpoints: - Cloud instance metadata endpoints for service discovery and IAM role enumeration - Internal HTTP s