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.

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