REPORT + CONTEXT for v0.203.0: the retry shape, the marker answer, R-220's shape

Records the decisions rather than only the code:
- POLL not ACK, decided on Scenario B against the ACTUAL promises — the
  no-target message gives no deadline and the card says 'within a day', so a
  5-minute tick is inside both and no text needed changing. If either promise
  tightens to minutes, go ACK-driven.
- The marker question: applied_marker lives in the guest's DataDir, which a
  rebuild destroys, so it cannot suppress a legitimate re-run. Left alone.
- R-220 candidate (b), corroborated rather than a wider prefix, reading
  /proc/mounts because the lsblk args are pinned in sudoers.

Live: Scenario C proven on demo-hp WITH a positive control — the job ran once
and logged nothing. A first reading counted 2 lines that turned out to be the
start-up reconcile, not the retry; the instrument was corrected before the
conclusion. Scenarios A and E are deliberately NOT live-proven here: both need a
rebuilt box, and that state arises naturally in Part 4.

CONTEXT.md

@@ -1776,6 +1776,30 @@ Last updated: 2026-06-13 (v0.60.0 backlog-Medium cleanup)
 
 ---
 
+## THE TWO RULES THE RECOVERY JOURNEY LEANS ON (v0.203.0, 2026-08-06)
+
+> **1. A credential the hub stages is collected by the box, not waited for.** The reconcile that
+> collects runs on a tick for exactly as long as the box's own declaration says it needs one — and
+> stops the instant a target exists. It is driven from `OffboxReportStatus().State`, the same statement
+> the hub acts on, so the two can never disagree about whether a retry is wanted.
+>
+> **2. A mount Felhom itself made is not "something else".** Enrolment mounts a drive twice — the
+> managed path and a raw `/mnt/<name>` on the host — and the host survives a guest rebuild while the
+> guest's registry does not. The claimed check forgives a non-managed mount **only when corroborated**
+> by the same device also being mounted under the managed path. **A genuinely foreign mount is still
+> refused, and that fence has its own test.**
+
+**Why both are stated here rather than left in the code:** each was a dead end that kept the unaided
+recovery journey failing, and each looked correct in isolation. R-218's declaration half shipped and
+worked while nothing consumed what it asked for; R-220's check was right about foreign disks and wrong
+about our own. **Neither is a bug in the thing it guards — both are about what runs, and when.**
+
+Two things that must not be "simplified" back:
+- **The settle gate stays.** The retry goes through `ReconcileWhenSettled`, so the day-0 floor race is
+  unchanged. A retry that skipped it would trade one defect for another.
+- **The R-220 exemption is corroborated, never a prefix.** Widening it to any `/mnt/*` path offers a
+  disk another system is using for formatting — the red-proof shows exactly that.
+
 ## THE UNLOCK PATH'S RULE (v0.202.0, 2026-08-06) — state it before changing anything there
 
 > **On the recovery unlock path the customer is blamed only after a real attempt REFUSED their code.