fix(agent): deploy workloads into their own namespace, not the agent's

[agustincelentano]

What

worker_default_env derives K8S_NAMESPACE from var.namespace, which is documented as "Kubernetes namespace where the nullplatform agent will run" and defaults to nullplatform-tools. Every k8s-scope worker therefore deploys its application pods next to the agent instead of into nullplatform.

Why it's a bug and not a choice

The same locals.tf block documents the intended value a few lines below:

#               - { name: K8S_NAMESPACE, value: nullplatform }

And nullplatform/scopes ships K8S_NAMESPACE: nullplatform as the k8s scope default, which is where every pre-worker agent deployed. The code and the documentation disagree.

How it showed up

Migrating a client from the pre-worker agent to v7.7.0, a freshly created scope deployed its pod into nullplatform-tools while every pre-existing scope stayed in nullplatform. Same cluster, same config, split by whether the scope predated the worker orchestrator.

The change

Splits the two concepts. var.namespace keeps meaning where the agent runs; the new var.workload_namespace is what the workers receive, defaulting to nullplatform.

Callers that actually want workloads next to the agent can set workload_namespace to the same value as namespace.

Compatibility

Behaviour changes for anyone who left namespace at its default and has been running worker-orchestrated scopes: their new workloads move from nullplatform-tools to nullplatform. That is the documented and historical target, so this restores intended behaviour rather than changing it, but it is worth a line in the release notes.