v1.50.3: sizes are not coordinates (HP-1502-01)

The ±4 bound from v1.50.2 measured view_box[2:4] and room w/h with the same
ruler as coordinates, so zero and negative sizes still passed the schema —
and viewBox='0 0 0 0' draws nothing on every client, with the static card
computing aspect-ratio: 0 / 0 on top. _EXTENT now requires strictly positive
sizes with a floor of one thousandth of the canvas (1 render unit — far
below any real room, keeps the maths finite); coordinates stay allowed to be
negative, a crop origin legitimately sits past the edge.

Defensive layer for stores that already hold a broken viewport: spaceModels
falls back to the whole canvas — both cards render from that model, so both
get the fallback — and a legacy rectangle with a negative size reads as the
same rectangle drawn from the other corner.

Also: the room settings button is the bottom row of the room card, and the
room name renders in the same spot in view and plan modes (owner's request,
committed earlier on dev).

docs/TESTING.md

@@ -239,6 +239,13 @@ Run the *core flows* (marked ★ below) in each environment at least once per mi
       on the plan after a reload. Same for each tap action and each fill mode
       [auto: backend test_every_display_mode_the_editor_offers_is_accepted and
       neighbours, test_a_marker_showing_its_value_can_be_saved]
+- [ ] Sizes are positive (v1.50.3, HP-1502-01): view_box or room w/h of zero
+      or below is refused; a store that already holds one opens on the full
+      canvas, not a blank screen [auto: test_sizes_are_not_coordinates + unit
+      safeViewBox fallback]
+- [ ] Room card layout (v1.50.3): the settings button is the bottom row of the
+      card and the room name sits in the same spot in view and plan modes
+      [manual; verified by vb-coordinate measurement]
 - [ ] Geometry bounds (v1.50.2, HP-1501-01): a config with a 1e100 room
       vertex is refused by the server; one already stored still renders with a
       sane frame [auto: test_geometry_magnitudes_are_bounded + unit