Start every worker thread through the executors module

Thirty-nine spawn sites in dr-ui, and one in the Android entry point,
called std::thread::spawn or a Builder of their own, and most of the
threads they started were <unnamed> in a panic message or a profiler.
Each now calls executors::spawn with its executor and a role, so the thread is
named <executor>:<role> — net:sync, decode:thumbs, io:catalog-open —
and knows which executor it is on. The three that already set a name
(automation, import, prefetch) keep their name as the role.

Behaviour is unchanged: each job still gets a thread of its own when it
starts, and spawn panics where std::thread::spawn did.

The module's documentation now says how a job is assigned: by what it
spends its time on, so a sweep that fetches bytes and then decodes them
is Decode, and a sidecar write that touches the catalog is Network.

Left as they were: the segmentation and refine workers in masks_ui.rs,
which another change is reworking, and test-only threads.

ui/dr-ui/src/executors.rs

@@ -35,12 +35,15 @@
 //!
 //! # Which executor a job belongs to
 //!
-//! By what it spends its time waiting on. A worker that builds a network
-//! runtime and moves bytes to or from a server is [`Executor::Network`], even
-//! when it touches the catalog on the way; one that decodes images or runs a
-//! CPU pass over their pixels or embeddings is [`Executor::Decode`]; one that
-//! drives the GPU is [`Executor::GpuSubmit`]; the rest — catalog, files, local
-//! sockets, relaying a channel to the log — is [`Executor::Io`].
+//! By what it spends its time on. One that decodes images or runs a CPU pass
+//! over their pixels or embeddings — the thumbnail and metadata sweeps, face
+//! indexing, grouping, repairs — is [`Executor::Decode`], even when it fetches
+//! the bytes first. One that drives the GPU — batch export, a merge — is
+//! [`Executor::GpuSubmit`]. One whose work is moving files or metadata to or
+//! from a server — sync, sidecars, fetches, trash, login — is
+//! [`Executor::Network`], even when it touches the catalog on the way. The
+//! rest — opening the catalog, a backup, a local import, relaying a channel to
+//! the log — is [`Executor::Io`].
 
 use std::cell::Cell;
 use std::thread::JoinHandle;