Record the guards, the narrowing, and the two things I could not do

R-273's owed guards are both built and closed. R-291 records what CI stopped
covering and why, so it can be widened deliberately rather than discovered.
R-292 is new and was found by a test failing for the wrong reason:
artifact_sha_invalid conflates "version missing", "registry unreachable" and
"bad sha" into one message. v0.102.0 works around it by ORDERING -- the probes
run first, so an unreachable registry is reported as unreachable -- but the
message itself is untouched.

CONTEXT gains the rule this session is about: a check and the policy it enforces
must read the same number from the same place, or they drift and the drift looks
like a defect in something else. Two corollaries, both of which cost something:
a bounded check must print what it stopped covering on every run, and an
unreadable policy is INCONCLUSIVE rather than unbounded.

Stated in the report rather than glossed: Part 4 (finding receipts for the twelve
downgraded claims) was NOT done and is a shortfall, not a decision -- splitting
it would have produced exactly the half-checked green the exercise exists to
prevent. Part 5 was droppable and dropped. The tag-push green is not re-proved
tonight and is not claimed; the evidence offered is runs 190 and 216.

STATUS.md

@@ -1,6 +1,6 @@
 # STATUS — what works, what's broken, what's next
 
-**Updated 2026-08-09.**
+**Updated 2026-08-09 (evening).**
 
 > **A view, not a source.** `documentation/backlog/OPEN-ITEMS.md` is the authority; this page restates
 > part of it in plain words, and **nothing may exist only here**. Not `CONTEXT.md`, which is technical
@@ -42,6 +42,38 @@ destroyed on purpose and its files came back byte for byte identical — four ti
 their recovery code got everything back with **no command line inside the machine at any point**,
 in 72 seconds. The two rough edges that walk found are also gone. *(R-201, R-252, R-253 — closed.)*
 
+## The guard is in. An approval that cannot be installed is now refused.
+
+**Yesterday morning every install in existence failed for hours, and nothing would have stopped it
+happening again. Now something does.** When you press Save on the Day-0 artifacts, the hub checks —
+before it writes — that each version you are vouching actually has its git label **and** that its file
+can actually be downloaded. If either is missing it refuses and tells you which, for which version,
+and the one command that fixes it. **Hub v0.102.0 is live.**
+
+Three details worth your knowing:
+- **It checks the exact file the installer fetches first** — the one whose absence broke Friday — not
+  some other file that happens to exist. A test pins that, because probing the wrong file is precisely
+  how the failure stayed invisible.
+- **"Could not check" also refuses**, with a different message. Saving with a warning would read as a
+  success, and we have the scars. **There is no override**: the registry is on your own server, so if
+  it is unreachable the approval can wait.
+- **A second machine now catches it one step earlier** — the agent repo refuses to consider a release
+  complete unless its label and its package both exist.
+
+## The red repository is green, and the two rules now share one number
+
+The tidy-up keeps the newest ten versions; the check demanded every version ever labelled still be
+downloadable. Both are sensible and together impossible, so the red would have returned on your next
+publish. They now read the same number from one file. **What the check no longer covers, plainly: a
+version older than the ten is no longer asserted downloadable** — its label and its config files still
+are — and it prints which ones it dropped on every run so this cannot go quiet.
+
+**One thing I could not establish, and I am not guessing.** Who actually deleted the old versions is
+**still unknown**. Gitea keeps no deletion trail: no cleanup rule is configured, the version table has
+no deleted-marker, the activity feed shows no package operation, and the server log no longer reaches
+back that far. I also **withdrew my own claim from yesterday** that the logs showed no deletion — the
+logs did not cover the window, so they never said anything.
+
 ## The rehearsal finished. The data came back byte for byte; the journey did not.
 
 **We wiped a working demo machine and put it back. All four test files returned identical — including