fix: surface HTTP fallback error when HTTPS registry login fails

[vatsalgargg]

- What I did
Fixes #5253. I fixed an error-masking issue in docker login where the CLI would swallow the initial HTTPS connection failure and only surface the subsequent HTTP fallback error when communicating with an insecure registry.

- How I did it
I modified the error handling logic in cli/command/registry/login.go. The patch intercepts the error returned by the daemon, checking if the user explicitly requested an https:// prefix and if the resulting error string contains an http:// failure (indicating a protocol downgrade). If both conditions are met, it wraps the error using fmt.Errorf to explicitly inform the user that their requested HTTPS connection failed and the daemon was rejected after falling back to HTTP.

- How to verify it

1. Configure a Docker engine with an insecure-registries entry pointing to a registry that rejects plaintext HTTP traffic (e.g., a Harbor instance throwing 403s on port 80).
2. Attempt to login explicitly using HTTPS: docker login https://<registry-ip>
3. The CLI will now explicitly output the wrapped error explaining the HTTPS failure and HTTP fallback, rather than just returning a confusing 403 Forbidden HTTP error for an HTTPS request.

- Human readable description for the release notes

docker login: surface the original HTTPS connection failure when falling back to HTTP for insecure registries

[vatsalgargg]

Hi team,

Just submitting this fix for #5253. It ensures the CLI doesn't swallow the original TLS/HTTPS failure when the daemon falls back to HTTP for insecure registries.

Tested locally via make cross. Let me know if you'd like any adjustments to the error string or if you need me to add any specific unit tests for this!