fix(ocireg): preserve default transport settings for HTTPS registries

[mabo235]

Summary

This changes the HTTPS transport setup in api/oci/extensions/repositories/ocireg
to clone http.DefaultTransport before applying the custom TLS configuration.

The previous implementation created a bare http.Transport with only
TLSClientConfig set. That dropped default transport behavior and caused
resolver failures against some public registries.

Root cause

The ocireg resolver currently replaces the HTTP transport with a new custom
transport that only sets TLSClientConfig.

That loses default transport settings which are preserved by
http.DefaultTransport.(*http.Transport).Clone().

In practice this showed up as intermittent Docker Hub auth failures during
artifact resolution, for example:

• GET https://auth.docker.io/token?...
• 403 Forbidden

A minimal resolver repro failed with the old transport and succeeded when using
a cloned default transport with the same TLS configuration.

Changes

• add newHTTPTransport(conf *tls.Config) *http.Transport
• use that helper in the HTTPS resolver path
• add a unit test that verifies the transport is cloned from the default
  transport and keeps its default settings while replacing TLSClientConfig

Validation

Tested with:

go test ./api/oci/extensions/repositories/ocireg -count=1

Additionally verified against a real resolver and fetch path on Linux where the
old behavior failed on public Docker Hub artifacts and the patched resolver
successfully resolved them.

[piotrjanik]

@mabo235 Another PR is available at #1887, which already covers how the HTTP client is created and should resolve that issue as well.

[mabo235]

@piotrjanik I checked this again against #1887, and it looks like the underlying ocireg HTTPS transport issue is covered there now. #1887 centralizes transport creation via a cloned http.DefaultTransport and the ocireg resolver uses that path as well, so I’m happy to close this one as superseded.