v0.207.0 — R-249: the retrieval passphrase leaves the page body; R-252/R-253: two refusals learn to say what to do

R-249. settings_security.html rendered the passphrase into a display:none
span behind a Megjelenit button. That toggle stops a browser DRAWING the value
and nothing else — the plaintext was in the response body of every render, so a
curl of the page returned it. Found by exactly that: it landed in a session
transcript while driving the documented rebuild path.

The codebase already stated this rule for the recovery code and this page did not
follow it (escrow_handlers.go: 'reveal (claim XHR only — R is NEVER templated
server-side into HTML)'). The page now carries only HasRetrievalPassword; the
value comes from POST /settings/retrieval-password/reveal — CSRF-covered because
POST, no-store, and LOGGED as an act, which reading it off the markup never was.

The tests assert the RAW RESPONSE BODY. Every test that asked what the customer
sees passed while the bytes carried the secret; that is why this survived.

Census: the render-then-hide pattern appears twice more — app_info.html (a real
per-install app password in a hidden span) and deploy.html. Filed as R-254, NOT
fixed here.

R-252. A rebuilt box keeps its drives but loses their REGISTRATION. The restore
page now states that before the customer presses anything, says the backups and
drives are both still there, and links to Tarhely > Meghajtok. Page and resolver
ask ONE question — HasRestoreDestination() reads the same
GetSchedulableStoragePaths() the scratch resolver reads.

R-253. The list promised 'a visszaallitas elobb ujratelepiti' three lines above a
refusal that fired BECAUSE the app was not installed. The promise was the wrong
half: reconstitution writes to the app's own GetStackHDDPath, which exists only
once the CUSTOMER has chosen a drive at deploy time. Auto-reinstalling would mean
the product making that choice for them. Copy now says to install first and routes
to /stacks/<app>/deploy.

Both notices are conditional — a healthy box renders as before, pinned by a test
that fails if either becomes unconditional.

controller/internal/backup/offbox_restore.go

@@ -171,7 +171,36 @@ func (m *Manager) offboxRestoreScratchDir(stack string) (scratch, nsRoot string,
 			}
 		}
 	}
-	return "", "", fmt.Errorf("nincs elérhető adatmeghajtó a visszaállításhoz")
+	// R-252: name the reason AND the way to act on it. This refusal is what a rebuilt box hits — the
+	// drives are physically fine and still mounted, it is their REGISTRATION that the destroyed guest
+	// took with it — and until v0.207.0 it said only that a drive was missing, which reads like data
+	// loss and offers nothing to do.
+	return "", "", fmt.Errorf("nincs regisztrált adatmeghajtó, ezért nincs hová visszaállítani — " +
+		"a meghajtók megvannak, csak újra kell csatolni őket a Tárhely → Meghajtók oldalon, utána " +
+		"ez a visszaállítás működni fog")
+}
+
+// HasRestoreDestination reports whether an offsite restore has anywhere on this box to write.
+//
+// R-252: the restore PAGE asks this question through the same helper the resolver answers it with,
+// so the notice cannot appear on a box that would restore fine (Scenario E) nor stay hidden on one
+// that would refuse. A second copy of the predicate is exactly how a page ends up promising what the
+// handler then refuses — which is the neighbouring defect, R-253.
+//
+// It mirrors the resolver's BOX-level branches (2) and (3) — the schedulable storage paths. Branch
+// (1), the app's own HDD path, is deliberately not consulted: an installed app's HDD path IS a
+// registered storage path, so the two cannot disagree in practice, and where they could, erring
+// toward showing the notice is erring toward telling the customer something true.
+func (m *Manager) HasRestoreDestination() bool {
+	if m.settings == nil {
+		return false
+	}
+	for _, sp := range m.settings.GetSchedulableStoragePaths() {
+		if strings.TrimSpace(sp.Path) != "" {
+			return true
+		}
+	}
+	return false
 }
 
 // RestoreOffboxScratch restores an app's latest offsite snapshot to an on-data-drive scratch dir