support for estargz was deprecated in 217318c (2023);
most projects using this code already removed their uses, and it was an experimental
feature.

This patch removes the functionality, but keeps the functions (for now) as no-op.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

…223) (#1046)

## Summary

- Bump `github.com/google/go-containerregistry` v0.21.5 → v0.21.6 to
pick up
[google/go-containerregistry#2302](google/go-containerregistry#2302)
— transport: allow bearer realm at same host:port as registry.
- Fixes [NCN-114223](https://jira.nutanix.com/browse/NCN-114223):
`mindthegap push bundle` (and downstream `nkp push bundle`) regression
against on-prem registries that colocate the registry and bearer-token
endpoint on the same private IP. e.g. for an internal Harbor at
`https://10.162.182.23:5000/library` the push aborted with `invalid
realm in www-authenticate: realm host "10.162.182.23" is a private or
link-local address`.
- Add regression test
`TestPushDockerArchive_BearerAuthSameHostLoopbackRealm` in
`cmd/mindthegap/push/imagearchive/push_test.go` that reproduces the
exact NCN-114223 error against v0.21.5 and passes against v0.21.6.

## Background

The realm-URL validation introduced in
[go-containerregistry#2243](google/go-containerregistry#2243)
(shipped in v0.21.5) rejects realms whose host resolves to a private,
loopback, or link-local IP. This is the right default for the cross-host
SSRF case (a malicious registry pointing the token endpoint at
`169.254.169.254` or a sister internal service), but it broke legitimate
on-prem deployments that serve their own token endpoint at the same
host:port as the registry.
[#2258](google/go-containerregistry#2258)
tracked the discussion;
[#2302](google/go-containerregistry#2302)
implements the agreed fix: keep the cross-host SSRF block, but skip the
private-IP check when the realm URL host AND port match the registry
host:port.

## Transitive dependency changes

Pulled in by `go-containerregistry` v0.21.6's `go.mod` via MVS
resolution:

- `docker/cli` v29.4.0 → v29.4.3
- `moby/moby/api` v1.54.1 → v1.54.2
- `moby/moby/client` v0.4.0 → v0.4.1
- `docker/go-connections` v0.6.0 → v0.7.0
- `klauspost/compress` v1.18.5 → v1.18.6
- `golang.org/x/{crypto,mod,net,sys,term,text,tools}` — minor bumps

Dropped (v0.21.6 removed estargz support in
[go-containerregistry#2288](google/go-containerregistry#2288)):

- `containerd/stargz-snapshotter/estargz` (indirect)
- `vbatts/tar-split` (indirect)

## Test fixture update

`images/manifest_test.go` is updated for the unrelated OCI-spec
compliance change in
[go-containerregistry#2269](google/go-containerregistry#2269):
`mutate.AppendManifests` now sets the index entry `ArtifactType` to the
image's `Config.MediaType` when the image manifest does not itself set
`artifactType`. For the Docker schema2 fixture in
`TestManifestListForImage_RemoteImage` this becomes
`"application/vnd.docker.container.image.v1+json"`
(`types.DockerConfigJSON`).

## Test plan

- [x] `go test -count=1 ./...` passes (155 tests).
- [x] New `TestPushDockerArchive_BearerAuthSameHostLoopbackRealm` fails
on v0.21.5 with the exact NCN-114223 error (`invalid realm in
www-authenticate: realm host "127.0.0.1" is a private or link-local
address`) and passes on v0.21.6 — bisected to confirm it is not a
tautology.
- [x] `go build ./...` passes.
- [x] `golangci-lint run ./...` clean.
- [ ] Manual verification against an on-prem Harbor with realm host ==
registry host on an RFC1918 IP (e.g. the reproducer environment in
NCN-114223).

## Out of scope

The two pre-existing govulncheck stdlib findings (`GO-2026-4982`,
`GO-2026-4980`, `GO-2026-4971`, `GO-2026-4918` — all `go1.25.x` fixed in
`go1.25.10`) are unrelated to this change.