`session.image.tag` can conflict with `container-images` in group profiles

[zachhannum]

Description

The Workbench Helm chart unconditionally injects default-container-image into the [*] profile from session.image.tag, with no conditional, no configuration knob, and no escape hatch. This causes a configuration desync when group profiles define their own container-images but do not override default-container-image.

Problem

In configmap-general.yaml, the chart constructs $defaultProfiles with default-container-image set from the session image tag:

$sessionTag := .Values.session.image.tag | default (printf "%s%s" .Values.session.image.tagPrefix $defaultVersion)

This value is injected into [*] unconditionally. The mergeOverwrite at line 95 preserves it unless the user explicitly sets default-container-image in their [*] profile override.

When group profiles (e.g., @clinical, @research) define their own container-images with allow-unknown-images=0, they inherit default-container-image from [*]. The inherited default is not in the group's allowed images, causing authorization errors when users try to start sessions.

Rendered example

Given this values.yaml:

session:
  image:
    repository: "my-ecr-repo"
    tag: "my-session-image"

config:
  profiles:
    launcher.kubernetes.profiles.conf:
      "*":
        allow-unknown-images: 0
        container-images:
          - "my-session-image"
      "@test-group":
        allow-unknown-images: 0
        container-images:
          - "group-specific-image"

helm template renders:

[*]
allow-unknown-images=0
container-images=my-ecr-repo:my-session-image
default-container-image=my-ecr-repo:my-session-image

[@test-group]
allow-unknown-images=0
container-images=group-specific-image

Users in @test-group inherit default-container-image=my-ecr-repo:my-session-image from [*], which is not in their container-images. The launcher API sends this unauthorized default to the UI, and session start fails with an authorization error.