Point architecture §7.1 at the executors module and record NFR-ARCH-1

§7.1 now says where its table lives in code, how the UI thread is
marked and guarded, and that the counts are a budget rather than a
bound until work is pooled by executor. The register's status note says
what is met — named, spawned through one module, block_on guarded and
tested — and what is not: pooling, a guard for synchronous file reads
and catalog queries, the two mask workers, and threads the core crates
start.

docs/dev/architecture.md

@@ -593,6 +593,13 @@ does not silently become uploadable by existing.
 The UI executor never blocks — this is the mechanism behind R4 and NFR-P9, which the requirements
 state as outcomes without saying how.
 
+**In code:** `ui/dr-ui/src/executors.rs`. `Executor` names the five and states each count with its
+reason (`Executor::threads`); `executors::spawn(executor, role, f)` starts a worker named
+`<executor>:<role>` and marks it with its executor. `run` marks its own thread as the UI executor
+before the window exists, and `executors::assert_not_ui` — called by `net_runtime`'s `block_on` —
+fails a debug or test build that blocks there. The counts are not yet enforced: a job still gets a
+thread of its own, and pooling by executor is where NFR-ARCH-2's priority classes will live.
+
 ### 7.2 Cancellation
 
 Cooperative, with tokens threaded through every long operation. Observed within 100 ms