FABRIC-3.5.md §XLIII: B3 settled -- the target drains its own queue at its own checkpoint

The last genuine design question in the reshuffle, and once again the
mechanism already exists, built for the structurally identical problem
and corrected twice in the field.

Delivery must execute the payload inside the target, but §XXXII retired
the pump so kernel-Hermes may not VM-EXEC into anyone. The payload must
wait somewhere the target consumes under its own power, at a moment when
doing so is safe -- and safe is the hard part, since interpreting
mid-word, mid-unwind or nested inside someone else's dispatch is the
reentrancy class this codebase has been bitten by repeatedly.

vm_core.c already has all of it: sk_vm_at_outermost_interpret() as the
predicate, a per-word checkpoint in execute_colon_word() gated on it, a
defer-don't-lose discipline for the nested case whose own comment
explains that a nested word does not own the stack it is running on, and
placement before the error and unwind checks so it only acts when the VM
is in a clean resumable state. That is the exact predicate, placement and
deferral semantics delivery needs, because the switcher had to answer the
same question.

Ruling: kernel-Hermes enqueues and publishes the fact, dispatching
nothing; the target drains its own queue in its own context at its own
outermost checkpoint. One published fact, two independent consumers --
the switcher for eligibility, the VM itself for drain -- and neither
dispatches into anyone.

Notes this is §XX's proven pattern generalized: the pump's defect was
never draining but draining from outside, and Hera was special-cased into
safety. Retire the pump and every VM does what she already does, so the
special case disappears by becoming universal. Also notes recursive drain
is prevented for free, since interpreting increments the same depth
counter that defines the boundary.

Names three constraints rather than leaving them to be discovered:
INPUT_BUFFER_SIZE is 1025 so a payload above 1024 bytes cannot be
interpreted in one drain, starvation is real but is the switcher's
existing risk rather than a new one, and draining one message per
checkpoint rather than the whole queue keeps the work bounded.

FABRIC-3.6.md: B3 cleared, B4 added for the payload bound.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VkM1zHGvBerLF6aqkHPweP

FABRIC-3.6.md

@@ -135,8 +135,11 @@ one message type owned by exactly one layer, no message shared.
       recommends the latter; unruled.)
 - [ ] **B2** — **Item 32**: `SK_SWITCH_MAX_SLOTS` is 16 and §XXXII made the switcher the sole
       mover of control. Constant bump or table redesign?
-- [ ] **B3** — **§XXXII.5.1**: the delivery hand-off is undesigned. **The last genuine design
-      question, and on the critical path.**
+- [x] **B3** — **CLEARED 2026-09-19 by `FABRIC-3.5.md` §XLIII**: the target drains its own
+      queue at its own outermost interpret checkpoint; kernel-Hermes publishes and never
+      dispatches. Reuses `sk_vm_at_outermost_interpret()` and the Stage 3 checkpoint.
+- [ ] **B4** — **Item 44**: payload bound or chunking against `INPUT_BUFFER_SIZE` 1025
+      (§XLIII.6.1). Decide before Phase 3.
 
 ## Phase 4 — Category B strip