drain object queues after each object

docs/script-api.md

@@ -259,8 +259,9 @@ The Registry is shared by the whole board, so namespace per-instance keys by `me
 ## Write functions
 
 Scripts never mutate the world directly. Each write appends an `Action` to the calling object's
-**output queue**; actions drain to a shared board queue between script calls and are resolved by the
-engine after the batch. The *subject* of a write is implicit and varies by function (see the table).
+**output queue**; the moment the hook returns, that object's ready actions are drained and applied
+by the engine — before the next object's hook runs. The *subject* of a write is implicit and varies
+by function (see the table).
 
 | Call | Subject | Cost | Description |
 |------|---------|------|-------------|
@@ -421,10 +422,10 @@ they are shape problems.
 
 ### Unwieldy — machinery that leaks
 
-- **The two-tier queue + `now()`/`delay()` model is subtle.** `now()` reorders by *enqueue
+- **The output-queue + `now()`/`delay()` model is subtle.** `now()` reorders by *enqueue
   recency* ("most recently enqueued action to the front"), which is position-dependent and easy to
-  get wrong; the object-queue → board-queue promotion plus per-object delay draining is a lot of
-  implicit state to reason about for "do X, wait, do Y".
+  get wrong; the per-object delay draining (leading delays eaten by `dt`, then the ready run applied)
+  is still a fair amount of implicit state to reason about for "do X, wait, do Y".
 - **Two persistence mechanisms.** Tags and the `Registry` are separate stores with separate APIs;
   cross-board state must pick one.
 - **Stringly-typed dispatch.** `send` and scroll choices route by function *name*; a scroll choice