avoid request stalls during proactive rebuilds

docs/wasm-runtime-architecture.md

@@ -136,6 +136,15 @@ refreshes the epoch deadline before its first guest call. Otherwise a component
 whose compilation outlasted the guest CPU budget would immediately trap in the
 following allocator/relocation call even though no guest loop consumed it.
 
+The proactive compiler and request workers coordinate through a per-unit file
+lock. Unit compilation writes and validates a process-unique temporary wasm
+file, then publishes it with an atomic rename. While another process holds the
+lock for a stale unit, a request may therefore keep using the last complete
+artifact instead of waiting across a transitive rebuild. Once the lock is
+released, normal freshness checks require the new artifact; a failed rebuild
+removes availability and surfaces the compiler error rather than serving the
+old unit indefinitely.
+
 ---
 
 ## 4. The workspace runtime
@@ -346,7 +355,10 @@ header free-functions are `inline`. The wasm backend exposes only declarations
   recycling.
   `scripts/test_cold_component_deadline.sh` separately compiles a deliberately
   cold component that exceeds the development epoch window and proves the
-  parent request still renders it.
+  parent request still renders it. The dependency-invalidation gate also holds
+  parent and child compile locks across a transitive source edit, proves a
+  warmed request returns the last atomically published result without waiting,
+  and then proves the new dependency result appears after rebuild completion.
 
 - **WebSocket end-to-end**: a headless client performs a raw WS handshake to
   `:HTTP_PORT` with path `/site/tests/websockets.ws.uce` (self-resolving