Let the develop column ask how wide it needs to be

The column was 280px, a number chosen for a tablet, with 380px bolted on
later for a desktop. Both were guesses at how much room the widest row
inside needs, and a guess is what cannot work here: the mode strip is one
chip per attribute the *operation set declares*, so the row is generated
and no constant in app.slint can track it.

When the guess came up short the failure was not a tidy clip. The
Flickable inside the column never had its `viewport-width` set, so the
viewport took its content's preferred width, and a viewport wider than
its Flickable is *centred* in it — the same rule the note on the seam's
`x: 0` already records a few lines below. So the column lost half of each
edge rather than one of them: "HISTOGRAM" read "ISTOGRAM", "Straighten"
read "aighten", Copy sat centred while Paste ran off the far side. It
looked like a rendering fault and it was an alignment one.

So the column asks instead of guessing. Every panel that can appear in it
— image, histogram, geometry, settings transfer, masks, repairs, adjust,
history — now publishes a `content-width`: how wide it has to be before
it starts clipping itself, read off its own layout rather than asserted.
Each declares that as its `min-width` too, and that is what makes the
aggregation automatic: `column` is a layout, so it already reports the
largest minimum among its children, and it does so for the panels that
come and go with the mode as well, which live inside `if`s and cannot be
named from outside. Grep `content-width` in ui/dr-ui/ui to see every
panel with a say in the answer. The mode strip is named explicitly only
because it is pinned outside that layout, so nothing else measures it.

There is no floor left. A floor is one more guess and the panels state
their own minimums now. The only thing still above the measurement is
`panel-max-width`, which is not a size but a policy — a column may not
take the window from the photograph it exists to serve — and it comes
from Rust beside `layout-class` because a width read from `root.width`
inside the layout that `root.width` depends on is a binding loop.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

ui/dr-ui/src/lib.rs

@@ -84,6 +84,22 @@ const MAX_DISPLAY_DIM: u32 = 2048;
 /// compact layout exactly as a tablet in portrait would.
 const EXPANDED_MIN_WIDTH: f32 = 820.0;
 
+/// TRACES: FR-UI-2
+/// The largest share of the window the develop column may take.
+///
+/// The column sizes itself to the widest thing it holds — the generated mode
+/// strip, the Copy/Paste pair, the histogram's axis labels — so on a rich
+/// operation set it would otherwise keep growing. This is where that stops.
+/// The majority of the window stays with the photograph, which is what the
+/// column is there to serve.
+const PANEL_MAX_FRACTION: f32 = 0.45;
+
+/// The floor under that share, so a narrow window still gets a usable column
+/// rather than one squeezed below the width its own controls were drawn for.
+/// Matches the 280px the column asks for at minimum: below this the cap would
+/// be doing the clipping the cap exists to avoid.
+const PANEL_MIN_WIDTH: f32 = 280.0;
+
 /// How long after the last change a draft frame is replaced by a sharp one.
 ///
 /// Above the interval between events in a drag, so an ordinary gesture never
@@ -2797,6 +2813,11 @@ fn apply_layout_class(window: &AppWindow, width: f32, panels: &PanelChoices) {
     window.set_expanded(expanded);
     window.set_layout_class(if expanded { "expanded" } else { "compact" }.into());
 
+    // FR-UI-2: the ceiling on the develop column, computed here for the same
+    // reason the class is — a width that both derives from and feeds the
+    // layout is a binding loop in Slint.
+    window.set_panel_max_width((width * PANEL_MAX_FRACTION).max(PANEL_MIN_WIDTH));
+
     if panels.class.get() != Some(expanded) {
         panels.class.set(Some(expanded));
         panels.panel.set(None);