feat: store AIWorkload CRs in a dedicated system namespace

[thbertoldi]

Summary

Consolidates AIWorkload custom resources into a single control-cluster namespace (default aif-workloads) instead of creating them in namespaces that mirror each workload's deployment target.

Today an AIWorkload CR lands in a caller-supplied namespace taken from the API path, which sprawls namespaces on the control cluster and conflates two concerns: where the CR is stored (a control-plane bookkeeping location) versus where the workload deploys (already carried by Spec.TargetNamespace). This change makes Spec.TargetNamespace the sole source of truth for deployment location and turns the CR's namespace into pure metadata.

This is safe because the downstream deployment identity (Fleet Bundle / HelmOp / Helm release name, target namespace, target cluster) is derived from the CR's name + chart + Spec.TargetNamespace + cluster — never from the CR's own namespace. A relocated CR with the same name recomputes identical downstream names, so the operator re-adopts the already-running workload with no redeploy.

Phase 1 — new workloads go to aif-workloads

• config: GetWorkloadNamespace() (env WORKLOAD_NAMESPACE, default aif-workloads).
• api: create always stores the CR in the workload namespace regardless of the request path; new path-less POST /api/v1/aiworkloads route. Update/delete keep addressing the CR by its real namespace so CRs created before this change still work during the transition.
• chart: creates the aif-workloads namespace (resource-policy: keep) and injects WORKLOAD_NAMESPACE into the manager. Operator cache stays cluster-scoped.
• ui: AppWizard / BlueprintInstallWizard now keep spec.targetNamespace as the true deploy target and address the CR by its real namespace for updates (previously form.value.namespace did double duty).

Phase 2 — opt-in relocation of existing workloads

cmd/migrate (shipped in the operator image; make build-migrate): idempotent, restartable relocation that, per workload:

1. Recreates the CR in aif-workloads (same name/spec/status, annotated ai-factory.suse.com/migrated-from).
2. Strips the ai-factory.suse.com/cleanup finalizer before deleting the source — the key safety step, so deletion does not tear down the live downstream workload.
3. Sweeps orphaned pull-secret Bundles labelled with the old namespace.

Name collisions are reported and skipped, never auto-renamed (a rename would change downstream identity). Runbook + Job manifest in docs/migration/. Migration is opt-in and only runnable after the Phase 1 image is deployed.

Testing

• go build ./..., go vet, gofmt clean.
• Unit tests: config accessor; API placement (CR lands in the workload namespace regardless of path, spec.targetNamespace preserved, path-less route); migration (relocate + finalizer-strip, already-in-place, collision-skip, resume partial run, dry-run, orphan-bundle sweep).
• Full envtest suite (all packages except /e2e) passes, including the aiworkload and installaiextension controller suites.
• UI: ESLint clean on changed files (0 errors).

Manual verification still needed

The UI create → manage(update) → delete round-trip — especially the App Instances "Manage" entry point — could not be exercised here and should be smoke-tested against a real cluster before merge.