R-109 + R-122: the recipe assembly stops dropping sections (hub v0.83.0)

AssembleDRRecipe's hostHalfShape/appHalfShape are ALLOW-LISTS, not the
forward-compat their comment advertised: a section an emitter adds is silently
discarded until it is named in both the shape struct and AssembledRecipe. No
error, no log, no failing test.

R-122 (found this session): that already happened and shipped. The controller
has emitted offsite_restic since fork-4 — the offsite recovery LOCATION — the
hub stored it for all three real customers, and appHalfShape never listed the
key, so no delivered recipe has ever contained it. It stayed green because the
fixture drAppHalf is hand-written and omits the field.

R-109: the agent's new backup_target is a new top-level host-half section and
would have been dropped identically, making the fix read as shipped while
changing nothing an operator can see.

3 tests built on halves read verbatim out of the live dr_recipe table, plus
2 red-proofs (each mutation asserted to have landed). vet rc=0, suite rc=0, 17 ok.

Registers: R-106 + R-109 dispositioned; R-105/R-106 were READY in ROADMAP with
no OPEN-ITEMS row (→ R-123, registered); R-124 filed on the "root" spelling.

hub/internal/api/testdata/host-report.golden.json

@@ -141,7 +141,8 @@
     ],
     "pbs": {
       "repo_id": "felhom-pbs",
-      "namespace": "root",
+      "namespace": "felhom-spike",
+      "namespace_state": "resolved",
       "latest_snapshot_id": "9001"
     },
     "drives": [
@@ -154,7 +155,13 @@
     ],
     "pve_storage": [
       { "name": "local-lvm", "type": "lvmthin", "content": "rootdir,images" },
-      { "name": "usb-backup", "type": "usb", "content": "backup" }
-    ]
+      { "name": "usb-backup", "type": "usb", "content": "backup" },
+      { "name": "felhom-pbs", "type": "pbs", "content": "backup" }
+    ],
+    "backup_target": {
+      "state": "resolved",
+      "storage_id": "usb-backup",
+      "mount_path": "/mnt/usb-backup"
+    }
   }
 }