Component images cannot build: the splatform bases are six years stale

The stratos-ui and stratos-backend component images have not built for years. With the GHCR authorization problem now fixed (#5763), this is what stands between the repository and a working Kubernetes image path.

What fails

Docker Build and Push (docker.yml) builds both components from deploy/Dockerfile.ui and deploy/Dockerfile.bk. Run 34355850982, triggered by the v5.5.3 release, failed in ui / linux-arm64; the other three matrix jobs were cancelled by fail-fast and fail the same way.

Error: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.29' not found
       (required by .../@lmdb/lmdb-linux-x64/node.napi.glibc.node)
gyp ERR! find Python - "python3" is not in PATH or produced an error
gyp ERR! stack Error: Could not find any Python installation to use
npm WARN notsup Unsupported engine for is-network-error@1.3.2:
     wanted: {"node":">=16"} (current: {"node":"12.13.0","npm":"6.12.0"})
SyntaxError: Unexpected token '?'
npm ERR! Failed at the @stratosui/devkit@0.0.1 build script

The build never reaches a push, so unlike the all-in-one image its GHCR authorization is still untested.

Why

The bases are from the SUSE era and were last rebuilt around 2020:

The ui build base carries node 12.13.0 / npm 6.12.0. The current tree is Angular 22 built with bun; SyntaxError: Unexpected token '?' is node 12 meeting optional chaining. No amount of retrying fixes this — the base cannot build the source.

These bases are not built from this repository, and the one workflow written to push them (container-push-base-images-develop.yaml) has been a silent no-op for years: it checks for GH_PACKAGES_USER / GH_PACKAGES_TOKEN, finds nothing, prints "Stratos containers are not supported at this time" and exits green.

Open question before any work starts

Is the Kubernetes component-image path still wanted? It should be answered first, because it decides whether this is a small change or a real piece of work.

Neighbouring evidence that it has been unmaintained for as long as the bases have:

• deploy/kubernetes/console/Chart.yaml is at version: 0.1.0 / appVersion: 0.1.0, with suse.de maintainer addresses.
• deploy/kubernetes/console/values.yaml still pulls from organization: splatform, not from ghcr.io/cloudfoundry.
• The documented deployment options are Cloud Foundry (recommended), Kubernetes via the Helm chart, and Docker via the all-in-one image. Only the first and third work today.

The all-in-one image is unaffected by any of this and now publishes correctly: it is built in release.yml from the staged release payload with deploy/all-in-one/Dockerfile — a Debian base, no splatform bases involved — and ghcr.io/cloudfoundry/stratos:5.5.3 is pullable.

Options

1. Retire the component images and the Helm chart. Smallest change: drop docker.yml, container-push-base-images-develop.yaml, the three splatform-based Dockerfiles, and document Cloud Foundry and the all-in-one image as the supported paths. Right if nobody is deploying the chart.
2. Rebase the images on maintained upstream bases. Build the ui image from an official node image for the build stage and nginx for the runtime; build the backend from the golang image and a slim runtime, matching what deploy/all-in-one/Dockerfile already does successfully. Drops the splatform dependency and the dead base-image workflow. Then point the chart at ghcr.io/cloudfoundry.
3. Rebuild the splatform base images. Reproduces the current structure but keeps a dependency on images this repository cannot build and an organization no longer involved. Not recommended.

Acceptance criteria

• docker.yml builds ui and backend for both platforms on a release tag and pushes to ghcr.io/cloudfoundry.
• The Verify Images job pulls and inspects what was pushed.
• The Helm chart references the images the repository actually publishes.
• Or, if option 1 is chosen: the dead workflows and Dockerfiles are removed and the docs no longer offer Kubernetes as a deployment option.

First resolve whether the Kubernetes component-image path should be retired or repaired. Then inspect docker.yml, container-push-base-images-develop.yaml, deploy/Dockerfile.ui, deploy/Dockerfile.bk, deploy/Dockerfile.init, and the console Helm chart; use the cited failed workflow as the starting diagnostic. Done means either the dead path and documentation are removed, or both images build, verify, publish, and match the chart references.