Specify how Helm release name and install target namespace are determined for ApplicationDeployment

[matlec]

Description

The Margo spec does not currently define how a Workload Fleet Management Client should determine:

1. The Helm release name to use when installing a chart from a helm component.
2. The Kubernetes namespace to install the chart's manifests into (i.e., the value passed to helm install --namespace).

These are two inputs that every WFM Client must supply when invoking Helm. With no spec-level fields or derivation rules, each implementation has to choose its own conventions.

Motivation

1. Every Helm-targeting WFM Client must choose some release name and target namespace when invoking Helm. Without spec-level guidance, each implementation invents its own convention. Implementations following different conventions cannot interoperate or be diagnosed consistently by operators.

2. Operators rely on Helm release names and target namespaces for:

• Debugging.
• Upgrade idempotency (the same ApplicationDeployment reconciled twice must result in helm upgrade against the same release).
• Resource lookup (Helm encodes the release name into the names of generated resources).

For completeness: the same gap also exists for compose deployments. Compose has its own concept of a project name via docker compose -p <project>, probably worth its own issue.

Proposed Solution (optional)

Add two Helm-specific fields under properties for helm components:

• properties.namespace (required, string) - the Kubernetes namespace into which the chart's resources are installed. Chosen by the WFM. The WFM Client MUST pass this value as helm install --namespace (and equivalent for upgrade / uninstall / status).
• properties.releaseName (optional, string) - the Helm release name to use for this chart. If present, the WFM Client MUST use this exact value. If absent, the WFM Client MUST derive a release name deterministically from the ApplicationDeployment's id and the component's name (exact derivation rule to be agreed in this issue). Determinism is required so reconciliation against the same ApplicationDeployment always targets the same Helm release.

Example shape:

spec:
  deploymentProfile:
    type: helm
    components:
      - name: digitron-orchestrator
        properties:
          repository: oci://northstarida.azurecr.io/charts/northstarida-digitron-orchestrator
          revision: 1.0.9
          namespace: northstar-prod        # NEW - required, chosen by the WFM
          releaseName: digitron            # NEW - optional override

[singhmj-1]

These fields are available under metadata object, but since we are not following the kubernetes manifest styling anymore, I agree that we should move them here and also explicitly mention their usage in the documentation. We should reword releaseName to release only, otherwise we should reword namespace to releaseNamespace to bring consistency.

[matlec]

@singhmj-1 I fell for it as well, but I think name and namespace in metadata actually serve a different purpose. Quoting from the spec:

name: When deploying to Kubernetes, the manifests name. The name is chosen by the workload orchestration vendor and is not displayed anywhere.
namespace: When deploying to Kubernetes, the namespace the manifest is added under. The namespace is chosen by the workload orchestration solution vendor.

Re-reading these definitions with the CRD framing in mind that we have established in #163, I believe that the spec actually talks about the name and namespace of the CR. The Helm release is not mentioned at all here.