v1.50.1: the v1.50.0 review (HP-1500-01..03)

- HP-1500-02: the stage budget was the absolute document coordinate, so any
  tall dashboard content before the card was billed as header and the stage
  collapsed to 0px. Measure our own chrome relative to the card plus a
  bounded (<=120px) allowance for what the viewport keeps above us; re-measure
  on window resize, remove the listener in disconnectedCallback.
- HP-1500-03, both layers: contentBounds opens a near-zero axis (< ~an icon)
  up to a 200-unit floor and ignores extra points outside a canvas envelope
  (-25%..125%) for FRAMING purposes only; the server bounds layout coordinates
  to +-4 — any finite float used to pass, and one 1e100 hid the plan from
  every viewer. A thin real room keeps its tight frame; the gate sensor past
  the edge still stretches it.
- HP-1500-01: no automatic double-transform — a correct layout and a stranded
  one are indistinguishable, and guessing wrong corrupts good data. Explicit
  admin command houseplan/geometry/repair: dry_run previews, the backup rides
  the same store write, undo restores, and routine layout writes now preserve
  unrelated store keys instead of eating the backup.

Tests: contentBounds guards (unit), layout coordinate bounds + repair
lifecycle (harness), card-below-content smoke. Inventory: 139 / 49 / 42 / 64.

docs/ARCHITECTURE.md

@@ -182,6 +182,17 @@ double click → properties dialog. In markup mode the "Opening" tool handles cl
 | `houseplan/plans/delete` | `name` | `{ok, removed}` / err `in_use` |
 | `houseplan/file/set` | `marker_id`, `filename`, `data` (b64) | `{ok,url,name}` (legacy, WS limit) |
 
+**If the v1.48 migration crashed halfway** (HP-1500-01): the config write
+landed, the layout write did not, and both triggers are gone — markers of that
+space sit in the old coordinates and nothing in the data can prove it. The
+`geom_pending` intent (v1.50.0) prevents this for any future migration, but
+cannot help an install that was already stranded. There is no safe automatic
+answer — re-transforming a layout that is actually correct would corrupt it —
+so the fix is explicit: `houseplan/geometry/repair {space_id, aspect}`
+re-applies the transform to that one space's positions. `dry_run: true`
+previews, the previous positions ride the same store write as a one-deep
+backup, and `undo: true` restores them. Admin-gated like every other write.
+
 **The canvas is square, the image is not** (v1.48.0). A space used to carry an
 `aspect`, and coordinates were normalised against it — x by the width, y by the
 height. That made every geometric question depend on a per-space number for no