v0.203.0: the box collects what the hub staged for it (R-218 consume half) + R-220's message

R-218's declaration half shipped in v0.201.0 and works. Its consume half never
existed. Reconcile ran exactly twice per process — at start-up and when the
recovery screen drives it — and BOTH fire before the hub has anything staged,
because the hub stages in RESPONSE to the declaration those runs precede.

Measured on the R-201 re-walk: unlock reconcile 11:43:07, hub staged 11:44:57
saying 'next cycle', a full report cycle ran 11:55:46, still unconsumed at
12:06. A guest command line applied it in 18 seconds — everything correct except
the trigger.

Bridge.RetryIfDeclared re-runs the SAME reconcile on a 5-minute tick, driven from
the box's own published declaration (OffboxReportStatus().State) — the very
statement the hub acts on, so the two cannot disagree.

Poll, not an ACK flag, decided on the promise: the no-target message says 'amint
megvannak' (no deadline) and the card says 'within a day'. Five minutes is inside
both by a wide margin and needs no hub change.

It stops by construction — a healthy box does no work and logs nothing — and the
settle gate is deliberately kept via ReconcileWhenSettled.

The marker was investigated and left alone: applied_marker lives in the guest's
DataDir, which a rebuild destroys, so it cannot suppress a legitimate re-run.

R-220's customer half: the refusal no longer tells the customer to choose from a
list that may be empty. It names the rebuild, points at the Meghajtók page, and
promises no outcome.

Red-proofs: remove the retry -> credential uncollected (the dead end reproduced);
drop the stop condition -> a healthy box hammers the hub; call Reconcile instead
of ReconcileWhenSettled -> settle gate bypassed; restore the old sentence -> the
impossible action returns.

28 packages ok, vet clean, all controller gates OK.

controller/internal/settings/refuse_message_test.go

@@ -0,0 +1,40 @@
+package settings
+
+import (
+	"strings"
+	"testing"
+)
+
+// ── SCENARIO G (R-220) — AN EMPTY LIST MUST EXPLAIN ITSELF ──────────────────────────────────────
+//
+// The old refusal said "choose an attached drive from the list" while the list was empty — on a
+// rebuilt box, for a reason the customer had no part in and could not see. Measured three times live.
+// A refusal that names an action the customer cannot perform is the I3 breach the campaign recorded.
+//
+// RED-PROOF: restore the old sentence and this FAILS on the impossible-action assertion.
+func TestRefuseAppNamespace_DoesNotNameAnImpossibleAction(t *testing.T) {
+	msg := refuseAppNamespaceUndeterminable
+
+	if strings.Contains(msg, "Válasszon a listából") {
+		t.Fatal("R-220's I3 breach RETURNED: the refusal tells the customer to choose from a list that may be empty")
+	}
+	// It must say WHY the list can be empty — the rebuild — so the state is explicable.
+	if !strings.Contains(msg, "újratelepítettük") && !strings.Contains(msg, "újra") {
+		t.Fatalf("the refusal must explain why the drive is unregistered; got %q", msg)
+	}
+	// And point somewhere a customer can actually go.
+	if !strings.Contains(msg, "Meghajtók") {
+		t.Fatalf("the refusal must name where re-attaching happens; got %q", msg)
+	}
+	// It must not promise an outcome it cannot know.
+	for _, forbidden := range []string{"biztosan", "garantál", "mindig sikerül"} {
+		if strings.Contains(msg, forbidden) {
+			t.Errorf("the refusal promises an outcome it cannot know (%q)", forbidden)
+		}
+	}
+	// The NAS refusal is a different situation and keeps its own wording — it points at a list that
+	// genuinely does have entries, so it is not the same defect.
+	if !strings.Contains(refuseAppNamespaceNetwork, "Válasszon csatlakoztatott meghajtót") {
+		t.Fatal("the NAS refusal was changed; it is a different situation and was not part of R-220")
+	}
+}