v0.234.0: seed installed_images at startup, so the label appears on an app nobody touched

The operator looked at demo-felhom the morning after v0.233.0 and found OpenGist
- up 15 hours, running exactly the catalog pin - showing no badge at all.
v0.233.0 wrote the record only from the four bring-up paths, so an app nobody
restarts carried no record indefinitely. On a quiet box that is every app, which
is the box we most want to see. The known limitation WAS the feature not working.

BackfillInstalledImages runs once at startup, beside BackfillDesiredState and
before the boot reconciler. It READS containers: starts nothing, restarts
nothing, writes no compose file. It never overwrites an existing record.

And it REFUSES to seed a partial observation, which is why this is not a
three-line loop: the badge reads a service-count mismatch as BEHIND, so seeding a
degraded app from what is visible would render 'Frissites elerheto' over an app
that is perfectly current. The bring-up paths may write a partial because they
follow a successful up -d where a gap is real news; a backfill meets any state.
Same data, two writers, two admission rules - deliberately.

Also fixes a calendar bomb of mine: the render test hardcoded catalog_since and
the string '46 napja', but the render path reads time.Now(), so it was green on
the day it was written and red the next morning. Now derived. Filed as R-457
with six other candidate files named as unchecked, not accused.

+5 tests (1724 -> 1729), 28 packages green. Red-proof of the partial guard run
and reverted; the wiring and its ORDER pinned by an AST walk.

controller/README.md

@@ -496,6 +496,13 @@ installed_images:
 - **NOT called from `StartStackServices`** — that path starts only the database service for the R-47
   restore window, and a partial record would overwrite a complete one.
 - **Absent means UNKNOWN and never means current.** Every `app.yaml` predating v0.233.0 has no entry.
+- **Seeded at startup for apps nobody touches (v0.234.0).** `Manager.BackfillInstalledImages` runs
+  once at boot, beside the desired-state backfill, and records what every deployed app is ALREADY on.
+  It only READS containers — it starts nothing and writes no compose file. It **never overwrites an
+  existing record**, and it **refuses to seed a partial observation**: `updateBadge` reads a
+  service-count mismatch as BEHIND, so a degraded app seeded from what is visible would show
+  „Frissítés elérhető" while being perfectly current. Without this, v0.233.0's label never appeared on
+  an app that simply ran (found on demo-felhom, 2026-09-03).
 - Its own docker seam (`Manager.installedExecFn`) carries a **context and a 30 s timeout**, which
   `composeExecCustomEnv`/`execCommand` do not — a bookkeeping read must not be able to wedge a
   lifecycle action.