Allowlist public Helm chart repositories for helm update jobs

[opdude]

What are you trying to accomplish?

Since proxy-egress-enforce was enabled, helm update jobs can't read the chart index for several widely used public charts. Each one fails at the first index.yaml request:

proxy | * egress not allowlisted kedacore.github.io
proxy | 403 https://kedacore.github.io:443/charts/index.yaml
proxy | 403 https://kyverno.github.io:443/kyverno/index.yaml
proxy | 403 https://argoproj.github.io:443/argo-helm/index.yaml
proxy | 403 https://open-telemetry.github.io:443/opentelemetry-helm-charts/index.yaml
proxy | 403 https://kubernetes-sigs.github.io:443/external-dns/index.yaml
proxy | 403 https://vmware-tanzu.github.io:443/helm-charts/index.yaml
proxy | 403 https://bitnami.github.io:443/sealed-secrets/index.yaml
proxy | 403 https://charts.external-secrets.io:443/index.yaml

The failure is silent: dependabot-core logs Latest version is (empty) and No update possible for keda 2.20.2, the job succeeds, and Dependabot closes the open update PRs as "no longer updatable". We lost open keda, velero, sealed-secrets, external-secrets and argo-rollouts PRs this way.

This PR adds the hosts to ecosystem_default_domains.helm under "Public HTTP chart repositories", next to prometheus-community.github.io, grafana.github.io and jaegertracing.github.io:

Host	Serves	Evidence it is public, provider-controlled
kedacore.github.io	KEDA chart repo (index.yaml and chart .tgz on the same host)	Documented in kedacore/charts README (helm repo add kedacore https://kedacore.github.io/charts); GitHub Pages of the kedacore org
kyverno.github.io	Kyverno chart repo (index.yaml and .tgz on the same host)	Documented in kyverno/kyverno charts/kyverno/README.md (helm repo add kyverno https://kyverno.github.io/kyverno/); GitHub Pages of the kyverno org
argoproj.github.io	Argo chart repo; tarballs on github.com/argoproj/argo-helm/releases	Documented in argoproj/argo-helm README (helm repo add argo https://argoproj.github.io/argo-helm); GitHub Pages of the argoproj org
open-telemetry.github.io	OpenTelemetry chart repo; tarballs on github.com/open-telemetry/opentelemetry-helm-charts/releases	Documented in open-telemetry/opentelemetry-helm-charts README; GitHub Pages of the open-telemetry org
kubernetes-sigs.github.io	external-dns chart repo; tarballs on github.com/kubernetes-sigs/external-dns/releases	Documented in kubernetes-sigs/external-dns charts/external-dns/README.md; GitHub Pages of the kubernetes-sigs org
vmware-tanzu.github.io	Velero chart repo; tarballs on github.com/vmware-tanzu/helm-charts/releases	Documented in vmware-tanzu/helm-charts README; GitHub Pages of the vmware-tanzu org
bitnami.github.io	Sealed Secrets chart repo; tarballs on github.com/bitnami/sealed-secrets/releases	Documented in bitnami/sealed-secrets README (helm repo add sealed-secrets https://bitnami.github.io/sealed-secrets); GitHub Pages of the bitnami org
charts.external-secrets.io	External Secrets Operator documented repo URL. It answers 302 to https://external-secrets.io/index.yaml	Documented in external-secrets/external-secrets deploy/charts/external-secrets/README.md (helm repo add external-secrets https://charts.external-secrets.io); TLS cert CN=charts.external-secrets.io; CNAME ghs.googlehosted.com
external-secrets.io	Redirect target serving the actual index.yaml; tarballs on github.com/external-secrets/external-secrets/releases	Custom domain of the external-secrets/external-secrets GitHub Pages site (Pages API cname: external-secrets.io); TLS cert CN=external-secrets.io; resolves to the GitHub Pages addresses

Tarball hosts are already covered: github.com and .githubusercontent.com (release asset redirects) are in github_infra_domains, and the two hosts that serve tarballs themselves (kedacore.github.io, kyverno.github.io) are in this list.

Anything you want to highlight for special attention from reviewers?

• Exact hosts only. The seven *.github.io entries are single orgs' GitHub Pages hosts, in the same form as the existing prometheus-community.github.io / grafana.github.io / jaegertracing.github.io entries. No *.github.io widening, and the existing attacker.github.io check in TestEgressAllowlist_AddedMissingDomainsAllowed still passes.
• external-secrets.io is also the project's docs site. It's here because it is where the canonical chart repo URL redirects to, not for changelog links. Without it, external-secrets helm updates fail outright.
• Why not per-job registries:. We tried declaring these as anonymous helm-registry entries in dependabot.yml first. The config validator rejects them (did not match one or more of the required schemas) because helm-registry requires username/password, so public anonymous chart repos can't be allowed that way.
• Overlap with Allowlist Traefik and Calico helm chart repositories #299. No host overlap (Allowlist Traefik and Calico helm chart repositories #299 covers Traefik and Calico), but both PRs append under jaegertracing.github.io, so whichever merges second needs a trivial rebase.

How will you know you've accomplished your goal?

• Positive probes added to TestEgressAllowlist_AddedMissingDomainsAllowed for the real index.yaml path on each host.
• Child probes (evil.<host>) added to TestEgressAllowlist_NewEntriesDoNotWidenBeyondExactHosts for all nine entries, plus a sibling probe attacker.external-secrets.io. Checked that the child probes bite: switching all nine entries to leading-dot form makes the test fail with new entries must not widen to: https://evil.<host>/payload for each of the nine. Reverted afterwards.
• Probe safety and ownership checked with the verify_host routine from .github/skills/add-egress-allowlist-domain: all addresses are public, each index.yaml returns anonymous 200 (except charts.external-secrets.io, a single 302 to external-secrets.io, which was checked as its own hop), and the cert subjects are as listed above.

Checklist

• I have run the complete test suite to ensure all tests and linters pass.
  script/test (Docker, -race -shuffle=on -count=2) passes; yamllint, gofmt -l, go vet ./... and go mod tidy -diff are clean.
• I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
• I have written clear and descriptive commit messages.
• I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
• I have ensured that the code is well-documented and easy to understand.