fix(infra): right-size MLflow memory limit to 4Gi from measurement

[Enskc05]

fix(infra): right-size MLflow memory limit to 4Gi from measurement

Follow-up to #32, which raised the limit to 6Gi. That number was a guess — the
pod had already been deleted, so the checkpoint size and peak memory could not
be measured at the time.

Measurement

With the fix from #32 in place (2 uvicorn workers) and a model upload that
completed successfully, Prometheus reports:

max_over_time(container_memory_working_set_bytes{
namespace="deephorizon-ml", container="mlflow"}[45m]) = 1.71 GiB

For comparison, the four pods that were OOMKilled under the old config all
peaked at 1.94–1.97 GiB — pinned against the 2Gi ceiling. So the limit was
genuinely the binding constraint, not a symptom of something else.

Change

• Memory limit 6Gi → 4Gi (~2.3× the observed peak). Request stays at 1Gi.
• Recorded the measured figure and the re-measurement query as a comment in the
  manifest. kubectl top does not work on this cluster — the metrics-server
  addon is not enabled — so the Prometheus query is the method, and
  next to the number it justifies.

Notes

This caps a chain that started with the training smoke test: the art
upload path now works end to end (params → Postgres, best_model.pt →
MinIO through the server proxy), with the limit sized from data rath
guessed.

Proxying artifacts through the tracking server remains the scaling c
flagged in #32 — 1.71 GiB for a U-Net checkpoint sets the baseline t
models grow.