fix(hermes): one delivery path -- a VM takes its own messages on its own turn, never on another's stack

FABRIC-3.5 SXXXII, closing FABRIC-3 SXXIX bug 2 (SXXXVI).  A send marks the
receiver for the switch signal; the VM's own loop on its native stack takes
its messages and yields; Hera's idle beat makes the pending switch instead
of running other VMs' messages on her stack; every VM gets switcher turns
from birth; the drain refuses any call outside the VM's own context (the
test: it held every relayed line before, none now).

Found on the way: amd64's first-entry frame left rsp 8 bytes off the SysV
entry alignment (#GP on the first interpreter run on a VM's own stack), and
a VM yielding from its loop was marked SWITCHED_OUT, which stopped console
relay after one message and would have made KILL refuse it.

Relay of four lines to a WIREBIND identity on all three ISAs, five
hot-plugged identities, and standard acceptance (POST 1052, hash
0x08873e0f44b7cb2a) all pass.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

v3/include/vm.h

@@ -669,6 +669,12 @@ typedef struct VM
                                          *   let a later switch-in from a different VM get
                                          *   silently bounced to the original caller instead
                                          *   of itself. */
+    int interpret_depth;               /**< How many vm_interpret() calls on this VM are in
+                                         *   progress, on any native stack (kernel only;
+                                         *   2026-10-14). Non-zero means this VM's
+                                         *   interpreter is mid-line somewhere -- possibly
+                                         *   on a stack that is parked right now -- and must
+                                         *   not be entered again to deliver a message. */
     /** @} */
 
     /** @name Stadium Identity (item 4.2, FABRIC-0.md §25.5)