Make AKS project creation recoverable after partial failures

## Problem

Project creation spans Kubernetes resources and, depending on the authorization model, Azure role assignments. Failures can currently leave partial state that the wizard reports only as a failed creation.

For native Kubernetes RBAC, `applyNamespaceManifest` creates the Namespace first and then applies children such as quotas, policies, and RoleBindings. If a child fails, the newly created, AKS Desktop-labeled namespace and any earlier children remain. The partial namespace can appear as a project, while retrying fails because the namespace already exists.

For Entra ID / Azure RBAC, the namespace may be created before an Azure role-assignment command or verification fails. Blindly deleting the namespace is unsafe because the assignment may have succeeded despite a timeout, Azure RBAC is eventually consistent, and deleting Kubernetes resources does not remove ARM assignments.

This follow-up should provide deliberate recovery semantics rather than attempting an implicit cross-system transaction.

## Proposed direction

### Kubernetes child failures

- Track whether the current invocation created the namespace.
- If a child apply fails, delete only that newly created namespace; namespace deletion cleans up namespaced children and RoleBindings.
- Preserve and report the original creation error.
- If cleanup also fails, report both failures and provide manual cleanup guidance.
- Never delete a namespace that existed before the invocation.

### Azure RBAC failures

- Make role-assignment creation and verification idempotent and safe to retry.
- Distinguish definite failure from an unknown outcome such as timeout/eventual consistency.
- Keep the created namespace and report partial success with a retry path when Azure access setup is incomplete.
- Track assignments created by the current invocation before offering cleanup.
- Never delete a pre-existing role assignment.
- Consider an explicit **Retry access setup** action rather than automatic cross-system rollback.

## User experience

- Show cleanup progress before presenting the final error when Kubernetes rollback is attempted.
- Clearly distinguish complete failure, partial success, successful cleanup, and cleanup requiring manual intervention.
- Do not display a partially configured namespace as a successfully created project without a warning or recovery action.

## Acceptance criteria

- A Kubernetes child failure does not leave a namespace created by that failed invocation when cleanup succeeds.
- Cleanup failure includes actionable manual-cleanup guidance.
- Retrying Azure RBAC access setup is idempotent.
- Timeouts do not cause deletion of resources whose creation outcome is unknown.
- Existing namespaces and role assignments are never removed by compensation.
- Tests cover successful creation, child failure with successful namespace cleanup, child failure with failed cleanup, Azure assignment failure, unknown Azure outcome, and safe retry.

Follow-up from #782.

Start by tracing the project-creation flow, including applyNamespaceManifest and the Azure role-assignment creation and verification paths. Define recovery states and tests for Kubernetes cleanup, Azure unknown outcomes, safe retries, and existing-resource protection; done means the acceptance criteria distinguish complete failure, partial success, successful cleanup, and manual intervention.

Written by the indexing model from the issue text.