v0.155.0 — the restore wizard read the wrong "is something running" flag

Fixes a defect shipped in v0.154.0, found by the operator on the first live
click-through of the new wizard.

backup.Manager carries TWO running booleans. `running` (read by IsRunning) is the
concurrency single-flight, acquired inside the background goroutine — and
RestoreOffboxScratch never acquires it at all. `opRunning` (read by RestoreStatus) is the
display flag, set synchronously by BeginRestoreOp in the handler.

The wizard sourced OpRunning from IsRunning(), so for „Ellenőrzés" and the full-restore
preparation — its two most-used and longest actions, both streaming from restic — the
execution step was unreachable: the page offered all three intents with live buttons
while a restore was running, and the progress banner contradicted the phase strip on the
same screen. Pressing anything there would have been refused by the handler, which is the
exact "offering a control guaranteed to fail" dishonesty R-48 exists to remove.

Fix: restoreOpInFlight(st) behind a documented seam, fed by a SINGLE RestoreStatus() read
per render so the strip, the suppression decision and the running-op name cannot diverge.

Why the tests missed it: the Scenario-E table proved deriveWizardStep behaves correctly
GIVEN OpRunning=true, but nothing proved the handler ever computes true — hollow at
exactly that seam. TestRestoreOpInFlight_UsesDisplayFlagNotConcurrencyFlag now drives a
real Manager through BeginRestoreOp and asserts the render suppresses every form.
Red-proofed against the v0.154.0 shape.

Also: „Eredmény" was a dead label. The strip's highlight is now its own derived Phase,
separate from Step — a finished restore returns to the intent step (everything available
again) while the strip reads „Eredmény" and an outcome card shows the result. Bounded by
restoreResultWindow (10 min) so a stale result cannot look fresh, and bound to the app so
a finished bookstack restore does not light immich's page with bookstack's message. The
card survives a reload; the redirect flash does not.

No new agent coupling — MinAgent stays 0.90.0.

CONTEXT.md

@@ -7,7 +7,27 @@
 >
 > Ask Claude Code: "Please update CONTEXT.md with what we did today"
 
-Last updated: 2026-07-21 (v0.154.0 — R-48: one restore entry per app, intent as a described choice)
+Last updated: 2026-07-21 (v0.155.0 — R-48 follow-up: the wizard read the wrong running-flag)
+
+> **2026-07-21 — v0.155.0.** v0.154.0's wizard sourced "is an op running" from `Manager.IsRunning()`
+> — the CONCURRENCY single-flight, acquired inside the goroutine, and **`RestoreOffboxScratch` never
+> acquires it**. So the execution step was unreachable for „Ellenőrzés" and the full-restore
+> preparation: live buttons while a restore downloaded, with the progress banner contradicting the
+> phase strip on the same screen. Found by the operator on the first live click-through.
+>
+> **DECISION: display reads `RestoreStatus()` (the `opRunning` flag), never `IsRunning()`**, through
+> the named `restoreOpInFlight` seam, and the handler reads the status ONCE per render so the strip,
+> the suppression and the running-op name cannot diverge. The lesson generalises: `opstatus.go` is the
+> DISPLAY surface and says so in its own header — the concurrency flag is not a substitute.
+>
+> **The test lesson:** a table test over a pure function proves the function, not the caller. Scenario
+> E passed throughout because it injected `OpRunning=true` directly. The new test drives a real
+> `Manager` through `BeginRestoreOp` and asserts the render.
+>
+> **DECISION: „Eredmény" earns its place.** The strip's highlight is now `Phase`, derived separately
+> from `Step`: a finished restore is back on the intent step while the strip reads „Eredmény" and an
+> outcome card shows the result — window-bounded (10 min) and app-bound.
+
 
 > **2026-07-21 — v0.154.0 (R-48).** Collapses the offsite restore controls to a single
 > „Visszaállítás…" entry per app row plus a per-app wizard at `GET /backups/restore/app?name=<app>`.