fix(bash image): full python stack + POD_POOL_<LANG> actually warms replicas

[aron-muon]

Summary

Two user-reported issues, fixed together because the second is what makes the first visible to users:

1. `ModuleNotFoundError: No module named 'xlsxwriter'` (and reportlab / python-docx / python-pptx / pdf2image / ...) from `bash_tool` — the bash image only had 5 apt-installed Python packages, so LC's `python3 -c "..."` reaches via bash_tool failed for anything beyond numpy/pandas/matplotlib/openpyxl/Pillow.
2. `POD_POOL_BASH=N doesn't actually wire through and change the number of warm replicas` — the Python config wiring is correct on paper; the runtime side had a 60s image-pull timeout that the now-1.13 GB bash image regularly exceeds on a cold node, so every newly-created warm pod got torn down before going Ready.

Fix

Part 1 — full python stack in the bash image

Install the FULL pip stack from the same `docker/requirements/python-*.txt` files the dedicated python image uses, so `lang=py` and `lang=bash → python3 -c` become indistinguishable.

Now in the bash image: `xlsxwriter`, `reportlab`, `python-docx`, `python-pptx`, `pdf2image`, `docx2txt`, `docx2python`, `mammoth`, `openpyxl`, `scikit-learn`, `scipy`, `plotly`, `opencv-python-headless`, `pillow`, `numpy`, `pandas`, `matplotlib`, `seaborn`, `statsmodels`, `lxml`, `cryptography`, `pyarrow`, `sympy`, and the rest.

Three DHI-base-specific problems had to be worked around to get this building against the live `dhi.io/debian-base:trixie-debian13-dev`:

#	Problem	Workaround
1	`r-base-core` + `gfortran` transitively need `liblapack3` + `libgfortran5` pinned to stock `gcc-14-base=14.2.0-19`, but DHI ships `14.2.0-19+dhi0`. APT solver can't satisfy.	Removed both from the bash image. Dedicated `lang=r` / `lang=f90` per-language images still serve those callers; LC's bash_tool doesn't reach for them in practice.
2	DHI's hardened `libzstd1+dhi0` fails `dlopen()` (`ImportError: libzstd.so.1: shared object cannot be dlopen()ed`). Python's `_ssl.so` links libzstd → SSL completely broken → pip can't reach PyPI.	Force-downgrade to stock `libzstd1=1.5.7+dfsg-1` via `--allow-downgrades`.
3	Same `dlopen` issue on `libffi8+dhi0`. `_ctypes.so` links libffi → pandas/numpy/cryptography all crash at runtime.	Same fix: downgrade to `libffi8=3.4.8-2`.

These three are pre-existing breakages of the bash image build against the current DHI registry — `main` was also unbuildable today.

Part 2 — POD_POOL_ ready timeout

Why warm replicas weren't materialising: `PodPool._wait_for_pod_ready` hardcoded a 60s timeout. The unified bash image (~1.13 GB) regularly exceeds 60s on first pull. Every warm pod got torn down before going Ready, the pool stayed at 0, and the only log was a quiet `warning="Warm pod did not become ready, deleting"` with no indication WHY. Operators reading kubectl saw `replicas: 0` despite `POD_POOL_BASH=N` and nothing in our logs explained the gap.

Three changes:

1. Configurable timeout — new `POD_POOL_READY_TIMEOUT_SECONDS` setting, default 300s (5 min), bounded [30, 1800]. Documented in `.env.example`.
2. Early-abort on terminal pod states — `ImagePullBackOff`, `ErrImagePull`, `InvalidImageName`, `CrashLoopBackOff`, `CreateContainerConfigError`, `CreateContainerError`. A misconfigured image now fails in ~5s with the actual reason logged at ERROR, instead of waiting out the full 300s.
3. Loud diagnostic on real timeouts — when we DO hit the timeout (typically a slow image pull stuck in ContainerCreating), log at ERROR with the last-observed waiting reason and a hint telling the operator whether to bump the timeout or investigate the cluster.

The companion rollup log in `_create_warm_pod` was bumped from WARNING to ERROR for the same operator-discoverability reason.

Validation

• Build succeeds against `dhi.io/debian-base:trixie-debian13-dev` (final image ~1.13 GB).
• User's exact failing reproduction now works:
  ```python
  import xlsxwriter
  workbook = xlsxwriter.Workbook("/tmp/beispiel.xlsx")
  ws = workbook.add_worksheet()
  ws.write("A1", "Hallo")
  workbook.close()
  ```
  → xlsx written, 5,250 bytes.
• Full `docx + pptx + reportlab + pandas + numpy + matplotlib` import chain works.
• `./scripts/test-bash-megaimage.sh` — 11/11 languages pass (bash, python, javascript, typescript, go, java, c, cpp, php, rust, d); r and fortran properly marked skipped.
• 1,519 unit tests pass (+8 new pool tests covering the timeout + early-abort cases).
• `just lint` / `just format-check` / `just typecheck` — all clean.

New tests

`tests/unit/test_pool.py`:

• `test_wait_for_pod_ready_uses_settings_default` — picks up `settings.pod_pool_ready_timeout_seconds` when called with no explicit timeout
• `test_wait_for_pod_ready_early_aborts_on_terminal_waiting_reason[ImagePullBackOff/ErrImagePull/InvalidImageName/CrashLoopBackOff/CreateContainerConfigError/CreateContainerError]` — 6 parametrized cases asserting the abort happens in <5s on a 30s nominal timeout
• `test_wait_for_pod_ready_waits_through_container_creating` — pins that `ContainerCreating` is NOT terminal (the image is being pulled; the wait must continue)

Operator note

If you currently see `POD_POOL_BASH=N` not materialising warm replicas, this PR should fix it. If the new 300s default is still too short for your registry/node combo, bump `POD_POOL_READY_TIMEOUT_SECONDS` further. The new error logs will tell you which case you're in:

• `last_waiting_reason=ContainerCreating` → image pull is slow, raise the timeout
• `last_waiting_reason=ImagePullBackOff` → genuine image config error (wrong registry, bad tag, missing pull secret) — early-abort will catch this
• `last_waiting_reason=None` after Running → runner /ready probe wedged inside the pod

🤖 Generated with Claude Code

[github-actions]

🎉 This PR is included in version 3.5.4 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀