docs(convertx): record the measured install-test time

The first green install-test of the chart (Gitea PR #61) took 2m35s for the
whole leg - cluster creation, fixtures, pull, install and rollout wait
together. The estimate in settings.env had been around five minutes for the
pull alone, extrapolated from the runner's 96 MB/17.5s reference; that
reference does not transfer to ghcr.io on this runner.

INSTALL_TIMEOUT stays at 900s. A rollout-wait timeout is a ceiling, not a
cost - kubectl waits exactly as long as the rollout needs - so the headroom
is free on a good day and only spends time on a chart that is already
failing. The comment now states the measurement next to the reason.

README gets the other half: a 1.4 GiB image was expected to move the
all-charts expectation from Gitea #52 and does not, because the legs run
concurrently and that figure tracks the slowest leg rather than the sum of
the pulls.

README.md

@@ -164,6 +164,7 @@ Why it exists at all: the answer arrived once by accident. Gitea PR #48 correcte
 - **Exclusions come from the one parser**, `ci/run-install-test.sh --list-excluded`, and the excluded charts appear in the job summary **with their justification**, exactly as in the PR pipeline.
 - **The result is written down.** Every matrix leg records its own outcome next to the four facts that decide what the outcome means — date, runner label, `K3S_IMAGE`, `kubectl` version — and a final job records the verdict over the whole matrix. A green run nobody notes is unknown again next time. Per leg and not as one table, because a matrix leg only ever sees its own job summary.
 - **Expected runtime: 20 charts in 12m41s** (Gitea PR #48, one job, all legs concurrently on one Docker daemon). The figure is there so a later deviation is visible as one; compare it against the chart count the run prints in its own summary — 24 at the time of writing, and one more with every new chart. The job timeout is 30 minutes per leg and lives in `install-test.yml`, i.e. it is the same for both callers on purpose.
+- **A big image does not move that figure as much as it looks.** `convertx` was expected to, at ~1.4 GiB compressed — by a wide margin the largest image in the repo, and the reason its `settings.env` raises `INSTALL_TIMEOUT` to 900s. Measured on its first green run (Gitea PR #61) the whole leg took **2m35s**, cluster creation and rollout wait included, so it sits inside the existing envelope rather than setting a new one. Worth knowing before the next raised timeout is read as a prediction about the total: the legs run concurrently, so what the all-charts figure tracks is the **slowest** leg plus scheduling, not the sum of the pulls.
 
 ## Dependency updates (Renovate)
 

ci/convertx/settings.env

@@ -9,6 +9,15 @@
 # generous because ConvertX shells out to ~20 converter binaries at import
 # just to log their versions.
 #
-# 900s is pull + a full startup budget with room left over. The default of
-# 300s would not even cover the pull.
+# MEASURED, and the estimate was wrong in the safe direction: the first green
+# install-test of this chart (Gitea PR #61) took 2m35s for the WHOLE job -
+# cluster creation, fixtures, pull, install and rollout wait together. The
+# 96 MB/17.5s reference does not transfer to ghcr.io on this runner.
+#
+# 900s stays anyway, and deliberately. A rollout-wait timeout is a ceiling,
+# not a cost: kubectl waits exactly as long as the rollout needs, so a
+# generous number is free on a good day and only spends time on a chart that
+# is already failing. What it buys is the bad day - a cold registry, or a node
+# that has to extract the 1354 MiB layer onto slow disk. The default of 300s
+# would have no headroom at all for either.
 INSTALL_TIMEOUT=900