Run edge e2e in CI against the real federated architecture

[scotwells]

What this does

Runs the edge end-to-end tests in CI against the real thing customers depend on. Until now CI only exercised a single-stack stand-in — vanilla gateway, no extension server, no federation — so an entire class of problems could never show up until production. This adds a CI job that stands up the production-fidelity edge and drives real traffic through it:

• Two clusters — control plane and edge — wired the way production is.
• Real Karmada federation carrying configuration from the control plane out to the edge, the same delivery path production uses.
• The production gateway version, the Coraza WAF data plane customer traffic actually passes through, and the NSO extension server.
• The full edge scenario set: the firewall enforces, an offline origin fails cleanly, the branded error page shows, and one bad certificate can't break its neighbors.

It also makes the environment reproducible from a clean checkout, which it wasn't before — bringing it up previously relied on files a developer already had locally. Those fixes live in Taskfile.test-infra.yml:

• A tools task that installs the pinned binaries the environment needs (kind v0.32.0, karmadactl, kustomize, cmctl, chainsaw) instead of expecting them hand-placed.
• An eg-chart task that pulls the Envoy Gateway helm chart (gitignored under config/**/charts, so absent on CI) before its bundled CRDs are applied.
• An upstream-gateway-crds task that installs the Gateway-API CRDs on the control-plane cluster before cert-manager, which otherwise crashloops (it runs with enableGatewayAPI: true) and stalls bring-up.

Why it matters

A test is only as trustworthy as how closely it resembles the real thing, and CI is where we get that assurance on every change. Wiring the federated environment into CI means the edge's core guarantees are proven automatically, in a setup that mirrors production, before anything reaches customers.

Proven green

The federated job passed end to end on the runner: two-cluster bring-up, real Karmada federation, and the full scenario set — WAF blocking real SQL-injection and path-traversal requests with 403s, the config-dump parity gate confirming the proxy runs exactly the intended set, the branded error page, connector-offline handling, and single-cert isolation. Total ~16 minutes.

How to read this PR

The federated environment lives across the stack in #247 (#224–#228), and none of it is on main yet — so this branch merges that stack in order to have a complete environment for CI to run against. The reviewable change is two files: the new workflow (.github/workflows/test-e2e-federated.yml) and the environment tasks in Taskfile.test-infra.yml. Once #224–#228 land, this branch rebases onto main and the diff collapses to just those.

The three Taskfile.test-infra.yml reproducibility fixes (tools, eg-chart, upstream-gateway-crds) are really properties of the environment itself and would sit equally well in #226 — happy to move them there if you'd prefer the environment PR own them.

Merge order: the #247 stack first, then this.

Notes

• The job is heavier than the existing single-stack e2e (two clusters + a full Karmada control plane), so it's path-filtered to edge-relevant changes and carries a 60-minute ceiling. It runs alongside the current test-e2e.yml; once this proves stable, the older single-stack job can be retired.
• Karmada's cross-cluster networking is written for macOS dev hosts but works unchanged on the Linux runner (the apiserver is reached through a host-port mapping); the workflow only adds the inotify-limit and disk-space headroom a Linux runner needs.

Part of #247.