Three issues resolved: one closed by evidence, two answered by the replacement

012 named its own closing condition — a scenario with four images coming up —
and the scenario now stocks seven and has raised cleanly many times at the
memory the wrong diagnosis had raised.

001 is answered by the host reading the package database back after installing.
002 was NOT answered and was present here too, so it is a fix rather than a
note: a stale index is now named instead of reported as a failed install.

04-ISSUES/002-stale-package-index-fails-silently/00-report.md

@@ -1,8 +1,8 @@
 ---
-status: open
+status: resolved
 opened: 2026-08-22
-located-in: []
-fixed-by:
+located-in: [mesh-host]
+fixed-by: mesh-host — a stale package index is named rather than reported as a failed install
 amended-design:
 ---
 
@@ -38,3 +38,29 @@ the job is green.
   versions — or is an index sync part of the install step?
 - A partial sync is unsafe on the platform in use; a full upgrade is the only sanctioned fix.
   Does that make index freshness a scheduled node concern rather than a pipeline one?
+
+## How it is answered
+
+*2026-08-31. It was present in the replacement too, which is why this is a fix rather than a note
+saying the new mesh does not have it.*
+
+**The failure is named.** A machine asking for a version the mirrors have replaced now says so, and
+says what fixes it — a full upgrade of the machine.
+
+**It is deliberately not fixed by synchronising.** `pacman -Sy <pkg>` installs a package built
+against libraries the machine does not have: a partial upgrade, unsupported on this distribution,
+which surfaces much later as something apparently unrelated. That is a decision about the whole
+machine, and a host that made it silently while applying one resource would be taking a large
+decision in a small place.
+
+So the host distinguishes the two cases and leaves the decision where it belongs. **A declaration
+that is wrong and a machine that is out of date fail identically otherwise, and they are fixed in
+completely different places.**
+
+**And the package manager's own words were being thrown away** — the output was read into `_`, so
+the 404s that name the cause never reached anybody. Whatever it said is now part of the failure,
+which is the rule everywhere else here and was not being followed in the one place where the reason
+exists only in the output.
+
+*Checked by a stale-index failure being named as one, an ordinary missing package not being, a
+single mirror timing out not being, and a successful install still saying nothing.*