Record where the named executors stand

NFR-ARCH-1's register note says what b1d1c472 and 7be1efff met and what
they left, but outstanding.md, which exists to show the distance between
the register and the binary, had no entry, and catalog.md §6 still said
interactive work runs "on the decode pool with the I/O pool behind it"
when there are no pools.

outstanding.md §4 gains the entry: named and guarded, not bounded — the
counts are a budget, the guard covers block_on only, the two mask
workers and the core crates' threads are outside the module. catalog.md
names the executors the thumbnail and metadata work starts on and says
the counts are not yet enforced.

docs/dev/catalog.md

@@ -510,8 +510,11 @@ Failures increment `attempts` and set `not_before` to an exponential backoff. Af
 count the job is marked failed and attached to its image as a typed error (NFR-ARCH-4) — one
 corrupt file does not stall the queue, and the user can see which files failed and why.
 
-**A job runner never touches the UI executor**, and `Interactive` work runs on the decode pool with
-the I/O pool behind it (ARCH §7.1).
+**A job runner never touches the UI executor**, and `Interactive` work runs on the decode executor
+with the I/O executor behind it (ARCH §7.1). Those are named rather than pooled today: thumbnails
+on demand start as `decode:thumbs` and the sweeps as `decode:thumb-sweep` and `decode:metadata`,
+through `dr_ui::executors::spawn` and each on a thread of its own, and the thread counts §7.1 gives
+are a budget nothing yet enforces (NFR-ARCH-1).
 
 ---