Improve wizard validation for containerized Next.js/kind deployments

Summary

The PostHog wizard reported a Next.js dashboard integration as complete, but the deployed app in a local kind/Kubernetes environment did not emit events until we manually rebuilt/redeployed the dashboard image and passed the PostHog env values through both the build-time and runtime paths.

This made the wizard sit at "waiting for events" even though the local source integration looked complete.

What happened

The wizard added PostHog client code to the local dashboard source, including the Next.js instrumentation-client.ts integration. However, the active dashboard was running from a previously built Docker image in kind, so the deployed dashboard did not contain the new PostHog bundle.

For this Next.js dashboard, NEXT_PUBLIC_POSTHOG_PROJECT_TOKEN and NEXT_PUBLIC_POSTHOG_HOST also needed to be present during docker build, not only at container runtime. The kind deployment additionally needed those values passed through Helm extraEnv for server-side PostHog usage.

There was also a deployment-specific routing issue: /ingest requests were intercepted by the dashboard auth proxy and redirected to login instead of being forwarded to PostHog, so even bundled client events could fail to reach PostHog.

Issues encountered

• Wizard verified local source changes, but not the actually deployed dashboard image.
• Wizard did not surface that NEXT_PUBLIC_POSTHOG_* values must be available at Docker build time for Next.js client bundles.
• Wizard did not account for Helm/runtime env injection needed by the deployed app.
• Wizard verification waited for events without identifying that /ingest was being redirected by app auth middleware.
• A Helm arg generation bug was easy to introduce: optional env vars emitted as fixed extraEnv[0] / extraEnv[1] indexes can create a sparse array if one value is absent, producing an invalid Kubernetes env entry.

Suggested improvements

• Detect when the app appears to be running from Docker, kind, or Kubernetes, and warn that source changes require image rebuild, image load, and rollout.
• For Next.js, explicitly validate whether NEXT_PUBLIC_POSTHOG_* values are present during build, not just runtime.
• Add a deployment checklist for common paths:
  • Docker build args
  • container runtime env
  • Helm extraEnv
  • Kubernetes rollout restart/status
• During verification, test the deployed app's ingestion path directly, for example /ingest/capture/, and report redirects/auth failures clearly.
• Detect auth middleware/proxy rewrites that block PostHog ingest routes.
• When generating Helm examples, use contiguous extraEnv indexes when optional env vars are omitted.
• Avoid reporting the setup as complete until the wizard confirms an event from the deployed app, not just local code presence.

Expected behavior

The wizard should distinguish between "PostHog code was added locally" and "the deployed application is sending events." If deployment steps are required, it should either perform them when possible or provide explicit commands and validation checks.

Start with the Next.js instrumentation-client.ts integration and trace how the wizard validates source changes versus the deployed Docker image. Check the /ingest/capture/ path, Docker build-time variables, Helm extraEnv generation, and rollout checks. Done means the wizard distinguishes local code from deployed event delivery and reports redirects or missing deployment configuration clearly.