feat: Support IronBank base image for STIG compliance

[rdwj]

Problem

Some deployment environments require DISA STIG-compliant container base images from Platform One's IronBank registry (registry1.dso.mil). The current Containerfile hardcodes registry.access.redhat.com/ubi9/python-311:latest. While the sandbox's security layers are image-agnostic, we haven't validated the IronBank path or documented the swap procedure.

Proposed solution

1. Parameterize the base image: Add a BASE_IMAGE build arg to the Containerfile so operators can supply their own base image at build time without forking:

   ARG BASE_IMAGE=registry.access.redhat.com/ubi9/python-311:latest
   FROM ${BASE_IMAGE}

2. Validate with IronBank Python 3.11: Build and run the full test suite against registry1.dso.mil/ironbank/opensource/python/python311. Document any delta in behavior (file permissions, missing utilities, package install differences).

3. Document the swap procedure: Registry auth setup, pull secret configuration for OpenShift, and any STIG hardening that conflicts with or duplicates our own container hardening (read-only rootfs, dropped caps, non-root user).

4. STIG control mapping (stretch): Map the sandbox's 6 security layers against relevant STIG controls to show which are already covered and which need additional work.

Component

CI / build, Helm chart (chart/)

Alternatives considered

• Multi-base Containerfile: Separate Containerfiles per base image. Rejected — a single parameterized Containerfile is simpler to maintain.
• Chainguard images: Another hardened base image option, but IronBank is the standard for DoD/STIG environments which is the use case driving this.