Profile Controller: Allow Creating Kubeflow Profiles for Pre-existing Kubernetes Namespaces

[###](url) Checks

- [x] I have searched the [existing issues](https://github.com/kubeflow/dashboard/issues).
- [x] My issue is related to one of the components in the [`kubeflow/dashboard`](https://github.com/kubeflow/dashboard) repository.

### Kubeflow Version

26.03.1

### Kubeflow Platform

Manifests

### Kubernetes Distribution

RKE2

### Kubernetes Version

```shell
Client Version: v1.31.2+rke2r1
Server Version: v1.32.8+rke2r1
```

### Description

Currently, when a user creates a Kubeflow Profile for a namespace that already exists, the Profile Controller fails with a "Profile already exists" or namespace ownership conflict, even if the namespace was manually created beforehand and has never been associated with a Kubeflow Profile.

This commonly occurs when namespaces are provisioned outside of Kubeflow (for example, using kubectl create namespace ) before users register through the Kubeflow Central Dashboard.

**Current Behavior**
1. Administrator creates a namespace manually (kubectl create namespace rckr)
2. The namespace has no owner annotation.
3. A user registers through the Kubeflow Central Dashboard (or creates a Profile) using the namespace rckr.
4. Profile creation fails because the namespace already exists.

**Expected Behavior**

If an existing namespace:

- exists,
- does not contain an owner annotation, and
- has never been claimed by another Kubeflow Profile,

the Profile Controller should adopt the namespace by:

- setting the owner annotation to the Profile owner,
- applying the default namespace labels,
- enabling Istio sidecar injection (if configured),
- setting the Profile as the controller owner,
- continuing with normal reconciliation process

If the namespace already contains an owner annotation belonging to a different user, the Profile creation should continue to be rejected to prevent namespace takeover.

**Motivation**

Many organizations pre-provision Kubernetes namespaces before onboarding users to Kubeflow. Requiring the namespace to be deleted and recreated by the Profile Controller makes onboarding difficult and complicates integration with existing Kubernetes provisioning workflows.

Allowing safe adoption of unowned namespaces improves interoperability while maintaining ownership protection for namespaces that are already managed by Kubeflow.

**Proposed Solution**

Enhance the Profile Controller reconciliation logic to:

- Detect whether an existing namespace has an owner annotation.
- If no owner annotation exists:
- adopt the namespace,
- populate required annotations and labels,
- continue normal reconciliation.
- If an owner annotation exists and matches the Profile owner: reconcile normally.
- If an owner annotation belongs to another user: reject the Profile creation with an appropriate error.

### Reference Image

```shell

```