Wire the launch screen into the app

The app now opens on the login screen when there is nothing else to show
— no local paths and no configured library — and goes straight to the
images otherwise. Making someone click past a login they already
completed is pure friction.

  launch.slint       imported by app.slint, replacing the window rather
                     than overlaying it: there is no library to look at
                     until an account is configured
  launch_ui.rs       the Slint wiring, kept out of lib.rs so the launch
                     flow can change without touching the develop window

Login runs on a worker thread and posts results back through a channel,
since Slint's event loop is single-threaded and a 20-minute browser wait
cannot block it. The system browser is opened via xdg-open, never an
embedded webview (FR-NC-1).

Sign-out deletes the local credential even if server-side revocation
fails: a network error must not leave a usable secret on the machine.
Format tick-boxes persist on each toggle, so a selection survives a
crash before the library is opened.

Two things deliberately incomplete rather than faked:

  - "Choose folder" lists the account's folders and reports them, but
    there is no picker widget yet, so selection still happens via the
    connect example.
  - "Open library" logs the request. Opening a remote library needs the
    scan-and-cache path, which belongs with the catalog work in flight.

Earlier I broke the other in-flight dr-ui work by calling
slint_build::compile twice, which replaces the generated module. The
correct wiring is an import inside app.slint, which is what this does.

30 dr-ui tests passing; both launch paths verified by running the app.

core/dr-pipeline/src/descriptor.rs

@@ -57,6 +57,24 @@ pub enum Unit {
     Percent,
 }
 
+/// A control that does not reduce to a slider or a switch.
+///
+/// The core names the *kind* of widget; `dr-widgets` owns what it looks like
+/// and how it behaves (ARCH §3.3). This is deliberately a small closed
+/// enum rather than an open string: a UI must be able to match exhaustively
+/// and know it has covered everything the core can ask for.
+#[derive(Debug, Clone, Copy, PartialEq, Eq)]
+pub enum WidgetKind {
+    /// A tone curve, edited by dragging points on a grid.
+    ///
+    /// The underlying parameters are ordinary [`ParamKind::Scalar`]s — the
+    /// point coordinates — so a UI that does not implement the curve widget
+    /// can still present them as sliders and remain fully functional. That
+    /// fallback is the reason the points are scalars rather than an opaque
+    /// blob.
+    Curve,
+}
+
 /// The shape of a parameter's value.
 #[derive(Debug, Clone, PartialEq)]
 pub enum ParamKind {
@@ -70,6 +88,31 @@ pub enum ParamKind {
     Bool,
 }
 
+/// TRACES: FR-DEV-3a | FR-DEV-3b
+/// How an operation would like its parameters presented.
+///
+/// A *hint*, never a requirement. An operation's parameters are always
+/// individually addressable scalars; this only says that several of them
+/// form one conceptual control, and which widget draws it best. A UI is free
+/// to ignore it entirely and render plain sliders — the edit still works, it
+/// is merely more tedious.
+///
+/// Sitting on the operation rather than on a parameter is what allows a
+/// widget to span several parameters, which a curve necessarily does.
+///
+/// Declared through [`crate::Operation::presentation`] — a defaulted trait
+/// method rather than a field on [`OpDescriptor`], so the great majority of
+/// operations, which want plain sliders, say nothing at all.
+#[derive(Debug, Clone, PartialEq)]
+pub struct Presentation {
+    pub widget: WidgetKind,
+    /// The parameters this widget owns, in the order it expects them.
+    ///
+    /// Parameters absent from this list are presented normally, so an
+    /// operation can pair a curve with an ordinary strength slider.
+    pub params: &'static [ParamId],
+}
+
 /// One parameter of an operation.
 #[derive(Debug, Clone, PartialEq)]
 pub struct ParamDescriptor {