Tablet portrait is the expanded layout class, not the compact one

FR-UI-1's table has put tablet portrait in the compact class since the
register was written. D-N2 settled that it does not belong there: a
12-inch tablet is about 1024 logical pixels across in portrait and
EXPANDED_MIN_WIDTH is 820, so both orientations of both targets are
expanded, and compact fires only on a desktop window dragged narrow. The
code has always agreed - apply_layout_class reads the window's width and
nothing else - so the register was the last place still saying otherwise.

What portrait actually needed was a different axis. D-N7 docks the
develop column under the photograph on a tall window, set from the
window's aspect and independent of the layout class: a 960-wide portrait
window is expanded and wants the dock, a 1500-wide landscape one is
expanded and does not. That is a placement rather than a mode, so the
clause about the transition being continuous stands as written, and the
requirement now records the side the column takes as its own property.

FR-UI-2 gains one clause for the same reason. It said modality affects
control sizing and affordances "not layout", which D-N6 reversed: under
touch the group selector leaves the strip above the column for the tool
rail, and groups-in-rail in toolrail.slint is what moves it.

docs/requirements.md

@@ -543,16 +543,26 @@ construction. Phones are out of scope for v1 (§1.3); the layout family spans ta
 
 | Class | Typical | Develop layout |
 |---|---|---|
-| Compact | Tablet portrait, narrow desktop window | Canvas full-width; one collapsible panel at a time; filmstrip on demand |
+| Compact | ~~Tablet portrait,~~ Narrow desktop window | Canvas full-width; one collapsible panel at a time; filmstrip on demand |
-| Expanded | Tablet landscape, desktop | Filmstrip, canvas, and adjustment panel simultaneously |
+| Expanded | Tablet portrait and landscape, desktop | Filmstrip, canvas, and adjustment panel simultaneously |
 
 Layout class is a function of window size, not device type — a narrow window on desktop uses the
 compact layout, and the transition is continuous rather than a mode switch.
 
+The develop column's side — beside the canvas, or docked under it on a tall window — follows the
+window's aspect, independent of the layout class (`docs/ui-navigation.md` D-N7). A placement, not a
+mode.
+
+> **Amended 2026-09-06.** Tablet portrait is the expanded class, not the compact one: both
+> orientations of the 12-inch tablet clear `EXPANDED_MIN_WIDTH`, 820 logical pixels (D-N2). Compact
+> fires only on a desktop window dragged narrow. What portrait needs is the dock, which is the
+> aspect axis above and not a second class (D-N7).
+
 **FR-UI-2 — Input modality.** The interface detects and adapts to the active input method, which
 is independent of layout class: a tablet may have a keyboard and pointer attached, and a desktop
-may have a touchscreen. Modality affects control sizing and affordances (FR-DEV-3b), not layout.
+may have a touchscreen. Modality affects control sizing and affordances (FR-DEV-3b), not layout —
-Switching input mid-session shall be handled without restart.
+save for the group selector, which moves from above the develop column into the tool rail under
+touch (`docs/ui-navigation.md` D-N6). Switching input mid-session shall be handled without restart.
 
 **FR-UI-3 — Touch targets.** Interactive controls present a minimum 44pt hit target when touch is
 the active modality. Hit targets may exceed the drawn control bounds.