[Chat] Make the additional content locales configurable at runtime instead of hardcoding them at build time

[PolinaGurinovich97]

Description

The set of content locales a user can translate a toolset or application into is
a build-time constant. ADDITIONAL_CONTENT_LOCALE_CODES in
apps/chat/src/utils/locale.ts is a hardcoded array, today empty:

const ADDITIONAL_CONTENT_LOCALE_CODES: string[] = [];

buildAdditionalLocaleOptions() derives the "Add locale" popup's Language
dropdown from it, so an operator who wants their deployment to offer, say,
de-DE and fr-FR translations has to edit source and rebuild the app. Because
the array is empty by default, the locale control is currently hidden entirely
(#8787), so the feature ships switched off with no way to switch it on at
runtime.

These are content locales — user-authored Name/Description values stored on
the entity — not UI display languages. They are deliberately separate from
SUPPORTED_LANGUAGES, which only lists languages that have a full <code>.json
UI bundle, and a content locale needs no UI translation file to be offered. So
nothing about this list has to be known at build time.

Use case/motivation

An operator running DIAL for a multi-language organisation should be able to
decide which languages their authors may publish toolset and application
metadata in, and change that decision without a rebuild of the chat app —
the same way they already configure the default deployment, the ASR model, or
the MCP sandbox URL.

Concretely: one tenant offers en-US only, another adds de-DE and fr-FR
next quarter. Today the second case means a source change, a rebuild and a
redeploy of the frontend for what is a configuration decision.

There is already an established mechanism for exactly this shape of value —
a client-visible entry in CONFIG_DEFINITIONS
(apps/chat-api/src/app-config/config-registry/config-registry.constants.ts)
backed by an environment variable, surfaced to the frontend through
AppConfigContext (apps/chat/src/context/AppConfigContext.tsx). A new
config entry — e.g. content.additionalLocales, visibility: 'client',
backed by a comma-separated env var, defaulting to an empty list — would let
buildAdditionalLocaleOptions() read the list from context instead of from a
module constant, with no change to how the locales themselves are stored or
resolved.

Points worth deciding while implementing rather than after:

• Validation. Codes reaching the client should be well-formed BCP-47 tags;
  an operator typo should fail at boot (environment.config.ts validation),
  not render a broken dropdown.
• PRIMARY_LOCALE stays as it is. It is SUPPORTED_LANGUAGES[0].code and
  determines which locale existing backend data is stored under. Making the
  additional locales configurable must not make the primary one configurable
  — the doc comment in locale.ts already flags a reorder there as a breaking
  data-migration concern.
• Locales already stored on an entity. If an operator removes a code from
  the configured list, translations previously saved under it still exist in
  the data. The editor should keep showing and let the author delete them,
  rather than silently dropping them on the next save.
• Display names. Whatever renders a code as a language name needs to cope
  with a code the app has no UI bundle for (Intl.DisplayNames is the obvious
  candidate).

Related issues

• [Toolset] Language dropdown in Add locale dialog is too narrow and truncates its value #8787 — the locale control is hidden when no language is configured, which is
  the behaviour this issue would make configurable rather than permanent.

Confidential information

• I confirm that do not share any confidential information