Let a photograph leave: an export button, and a cache to leave from

dr-export could turn a frame into bytes and nothing could ask it to. This is
the button, and the place the bytes go.

**Everything is staged first.** An export bound for the server is written to a
local outbox and uploaded afterwards; offline is not a special case, it is the
same path with a drain that finds the server absent. Doing it the other way —
upload directly, stage only on failure — makes the failure path the one that
is rarely exercised and always broken, and a network drop mid-batch leaves
some exports existing and some not with nothing recording which. Staged first,
an export is finished the moment it is written and the upload is a promise
kept later.

The outbox sits beside the catalog rather than under the cache. dr_catalog's
cache already draws that line: passive entries are a convenience and go under
LRU, pinned ones are a promise and never do. An export awaiting upload is a
promise — the user was told it succeeded — and sweeping it for disk would
destroy the only copy. Bytes are written before the destination record, so a
kill between the two leaves an orphan the drain ignores rather than a record
pointing at nothing.

The status line says "Queued for Exports/2026", never "Exported to Nextcloud",
until it has actually landed. There is a test asserting that wording, because
the tempting shorter sentence is a claim the app cannot keep.

The drain runs on the sync pass, before the shards: a thumbnail shard can be
rebuilt from the originals and the catalog is an index, but a queued export
exists nowhere else.

`DevelopSession::render_for_export` renders the framed size rather than reusing
the frame on screen, which is deliberately viewport-sized (FR-DSP-1) — encoding
that would hand the user a soft, screen-sized file with nothing to say anything
had been lost (FR-EXP-9).

One compromise, recorded rather than hidden: the export runs synchronously on
the UI thread, so the window is unresponsive for the few hundred milliseconds
a full-resolution render and encode takes. Moving a DevelopSession and its GPU
pass to a worker is a larger change than one button earns, and it is batch
export that makes the wait intolerable rather than merely noticeable.

Still missing: the Nextcloud folder *picker*. The destination is typed into
Settings for now. `FolderBrowser` in launch.rs is already the reusable model
for it — it browses a remote tree and nothing about it is specific to choosing
a library root — but wiring it into the settings page needs a listing worker
and browser UI there, which is its own piece of work.

Carries in-flight work from a parallel session — presets, the develop copy and
paste, and the node schema's `presentation` and `enum` support. One misplaced
callback in settings_ui.rs is moved from `render` to `wire`: registered in
`render` it borrowed a `&SettingsController` into a 'static closure and would
not compile, and that file's own docs say render pushes properties while wire
connects callbacks.

992 tests pass, clippy and fmt clean. Traceability 48.3% -> 51.0%.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

core/dr-pipeline/src/sidecar.rs

@@ -66,8 +66,8 @@ use std::collections::BTreeMap;
 use std::fmt;
 use std::fmt::Write as _;
 
-use crate::descriptor::{OpId, ParamId};
 use crate::graph::EditGraph;
+use crate::preset::{resolve, Preset};
 
 /// Format version of the document itself.
 ///
@@ -348,27 +348,13 @@ fn merge_judgement(ours: u8, theirs: u8, remote_wins: bool) -> u8 {
 /// Reads [`EditGraph::capabilities`] — the same list the UI builds controls
 /// from — so an operation is persisted by virtue of being in the chain, with
 /// nothing to register and nothing to forget.
-fn capture(graph: &EditGraph) -> BTreeMap<(String, String), f32> {
-    let mut out = BTreeMap::new();
-    for cap in graph.capabilities() {
-        for p in &cap.params {
-            if p.is_modified() {
-                out.insert((cap.id.0.to_string(), p.id.0.to_string()), p.value);
-            }
-        }
-    }
-    out
-}
-
-/// Find the `'static` ids matching these names, or `None` if this build has
-/// no such parameter.
 ///
-/// Looking them up in the descriptors rather than leaking the file's strings
-/// is what bounds memory: an unrecognised name never becomes a `'static`.
-fn resolve(graph: &EditGraph, op: &str, param: &str) -> Option<(OpId, ParamId)> {
-    let cap = graph.capabilities().into_iter().find(|c| c.id.0 == op)?;
-    let p = cap.params.iter().find(|p| p.id.0 == param)?;
-    Some((cap.id, p.id))
+/// Delegated to [`Preset::capture`] rather than reimplemented: a version's
+/// parameters and a copied preset are the same values taken from the same
+/// list, and two routines building the same map would be two places for the
+/// non-default rule to drift.
+fn capture(graph: &EditGraph) -> BTreeMap<(String, String), f32> {
+    Preset::capture(graph).into_params()
 }
 
 impl Sidecar {