v0.205.0 — a run that skipped an app the customer selected is not successful (R-234)

THE VERDICT. The R-203 block already said "a warning beside a success is read as a
success" and applied it to ONE of the two shapes it describes: an app missing a
declared mandatory FOLDER made the run incomplete, while an app skipped ENTIRELY
still reported ok. Both do now. Which skips count, decided by measurement:
selected+deployed with no recovery unit YES; selected but NOT deployed no (named,
with what to do — a box left amber by an app somebody removed is a status nobody
reads); disconnected/decommissioned drive no (own signal); nothing selected no.
LastSuccess and SnapshotCount still record what WAS captured.

THE FILED MECHANISM WAS NOT THE MEASURED CAUSE, and saying so is the point. §3
stated that toggling an app on leaves it without a bundle so the first run skips
it. Measured on demo-hp: the run's own pre-dump phase calls captureAllRecoveryUnits
for every DEPLOYED stack, through admitApp, before the push — a unit moved aside
was RECREATED and the run reported ok. That state does not survive a run.

What actually produced the 2026-08-06 sequence: the manual run was dropped by the
single-flight while an earlier run was still going. runOffboxBackup returned nil,
the handler had already answered "A tavoli mentes elindult", and the card then
showed the PREVIOUS run's green verdict — read as covering the app just selected.
The decision is now taken synchronously in the handler and a dropped request says
so. The nightly path still returns nil on purpose: nobody asked, and it retries.

§7.3 measured before deciding: CaptureRecoveryUnit writes a few KB of compose +
manifest, only ENUMERATES dumps rather than creating them, is idempotent and does
NOT stop the app — and already runs inside the off-site run. So there is no wait to
remove for a deployed app and NOTHING was built.

28 packages ok, 9/9 gates. Four red-proofs, each asserted to have applied. Fixture
note: the shared provider's ListDeployedStacks returned nil, so Scenario A first
passed for the wrong reason; fixed with an opt-in deployed set that defaults to nil.

CONTEXT.md

@@ -7,7 +7,27 @@
 >
 > Ask Claude Code: "Please update CONTEXT.md with what we did today"
 
-Last updated: 2026-08-05 (v0.200.0 — R-193: the recovery screen, unlocking only)
+Last updated: 2026-08-06 (v0.205.0 — R-234: a run that skipped a selected app is not successful)
+
+> **2026-08-06 — v0.205.0 (R-234).** THE RULE: **a run that skipped an app the customer selected is
+> not a successful run.** The R-203 verdict block already said *"a warning beside a success is read
+> as a success"* and applied it to one of the two shapes it describes — a missing declared FOLDER
+> made the run `incomplete`, an app skipped ENTIRELY did not. Now both do. A selected-but-UNDEPLOYED
+> app is named with what to do but does NOT move the verdict, because a box left permanently amber by
+> an app somebody removed is a status nobody reads.
+>
+> **§7.3, MEASURED rather than assumed — and the answer was "already done".** `CaptureRecoveryUnit`
+> writes compose config + a manifest (a few KB), only ENUMERATES dumps rather than creating them, is
+> idempotent, and does NOT stop the app; the off-site run already calls it for every deployed stack in
+> its own pre-dump phase, through `admitApp`. So there is no wait to remove for a deployed app, and
+> **nothing was built**. Proven on demo-hp: a unit moved aside was RECREATED by the run.
+>
+> **AND THE FILED MECHANISM WAS NOT THE MEASURED CAUSE.** R-234 was filed as "the first run after a
+> toggle finds no bundle and skips the app". That cannot happen for a deployed app (above). What did
+> happen on 2026-08-06: the manual run was dropped by the **single-flight** while an earlier run was
+> still going; `runOffboxBackup` returned nil; the handler had already said „elindult”; and the card
+> then showed the PREVIOUS run's „✓ Rendben”. Fixed by taking that decision synchronously in the
+> handler. **The nightly path deliberately still returns nil** — nobody asked, and it retries.
 
 > **2026-08-05 — v0.200.0 (R-193 CLOSED).** The customer-facing recovery screen. Until now a customer
 > whose machine was rebuilt had everything needed to get their data back and no way to find out — the