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.

CONTEXT.md

@@ -7,7 +7,30 @@
 >
 > Ask Claude Code: "Please update CONTEXT.md with what we did today"
 
-Last updated: 2026-09-02 (v0.233.0 — update arc slices 1 & 2: the installed-images record + the update badge)
+Last updated: 2026-09-03 (v0.234.0 — the installed-images backfill, so the badge appears on an app nobody touched)
+
+> **2026-09-03 — v0.234.0. ONE GAP CLOSED, ONE TEST DEFECT OF MY OWN.**
+>
+> **1. A RECORD THAT ONLY THE BRING-UP PATHS WRITE NEVER REACHES A QUIET BOX.** v0.233.0 shipped with
+> "the record appears after the next lifecycle action" written down as a known limitation. One day
+> later the operator looked at demo-felhom and saw OpenGist — up 15 hours, running exactly the catalog
+> pin, **no badge at all**. The limitation WAS the feature not working. `BackfillInstalledImages` now
+> seeds the absences at startup by READING containers. **The general lesson: a feature that only fills
+> itself in on an event nobody triggers is, on the quiet installations, not shipped.**
+>
+> **2. THE BACKFILL IS STRICTER THAN THE BRING-UP PATHS, AND THE ASYMMETRY IS THE DESIGN.** The badge
+> reads a service-count mismatch as BEHIND. The bring-up recorder runs right after a SUCCESSFUL
+> `up -d`, where a missing container is real news; a backfill meets a box in whatever state it is in,
+> so a partial seed would render „Frissítés elérhető" over an app that is perfectly current. It
+> therefore refuses to seed anything it cannot observe COMPLETELY. **Same data, two writers, two
+> different admission rules — do not "make them consistent".**
+>
+> **3. A TEST THAT HARDCODES A DATE AND ASSERTS AN AGE IS GREEN ONLY ON THE DAY IT IS WRITTEN.**
+> `TestGroupD_BadgeRendersOnBothSurfaces` pinned `catalog_since: "2026-07-18"` and the string
+> "46 napja". The pure tests inject a clock; the RENDER path goes through the funcmap and reads
+> `time.Now()`. It passed on 2026-09-02 and was red on 2026-09-03. Now derived from the same clock the
+> code reads. **R-457** names six other test files that mix a literal date with `time.Now()` — as
+> unchecked candidates, not accusations.
 
 > **2026-09-02 — v0.233.0. TWO DECISIONS, AND ONE LIMITATION THAT IS NOT A DEFECT.**
 >