README: where an off-site restore puts the data (R-356, v0.219.0)

controller/README.md

@@ -571,6 +571,18 @@ Each app can define rich metadata in `.felhom.yml`:
     (they are the undo). The live recovery unit is still never overwritten, which is why the replay
     source is the scratch. Honesty surfaces (`OffsiteScratchPair`): dump age, an unstamped-pair
     warning, and the R-44 empty-dump sniff — all warn-level, none of them gates.
+  - **Where an off-site restore puts the data (v0.219.0, R-356).** `ReconstituteFromOffsite` and
+    `PlaceOffsiteRestore` resolve the destination with `Manager.GetAppDrivePath` — **the same
+    resolver `CaptureRecoveryUnit` wrote the snapshot with**: the app's `HDD_PATH` if it declares
+    one, `systemDataPath` otherwise. Before v0.219.0 both used the RAW `GetStackHDDPath` and read an
+    empty answer as *"the app is not installed"*, which refused **40 of the 53 catalogue apps
+    permanently** — those apps are correctly driveless — while telling the customer to reinstall a
+    running app "in the same place" they are never offered. **Three separate refusals now, three
+    separate sentences:** not deployed (`isStackDeployed`, asked of `ListDeployedStacks` and failing
+    CLOSED on a nil provider); deployed but no resolvable data root; and the R-351 placement mismatch,
+    which still requires `ack_placement=1`. **The 13 `needs_hdd` apps are unchanged.** The
+    capture-side raw `GetStackHDDPath` (`offbox_capture.go`) is fenced and must keep no fallback —
+    it resolves declared `userdata`/`import` file legs, which do not live on the system disk.
   - **The restore wizard (v0.154.0, R-48 — `web/restore_wizard.go`).** The offsite restore controls
     used to render as up to five inline forms per app row, two of which — the missing-only merge and
     the true reconstitution — were sibling buttons whose difference is whether the data comes back.