fix(ocap-kernel): enqueue async vat syscalls immediately when outside a crank

[sirtimid]

Summary

• When a vat's async operation (e.g. fetch) completes between cranks, the resulting syscall.resolve was buffered with immediate=false. Since no crank was active to flush the buffer, notifications were never delivered and the crank loop never restarted — causing the kernel to hang indefinitely.
• Add isInCrank() to the kernel store's crank methods. In VatSyscall, check isInCrank() to determine the immediate flag: during a crank, buffer as before; outside a crank, enqueue immediately to wake the run queue.
• This unblocks any vat method that chains multiple E() calls with real async I/O between vats (e.g. coordinator → provider(fetch) → coordinator → keyring → provider(fetch)).

Test plan

• All 1983 ocap-kernel unit tests pass
• All 62 kernel-test integration tests pass (persistence, liveslots, remotes, IO)
• New unit tests for isInCrank() (true during crank, false outside)
• New unit tests for out-of-crank syscall behavior (immediate=true)
• Verified with eth-wallet's redeemDelegation pipeline (5-hop E() chain with real fetch I/O) — previously hung, now completes

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes core syscall-to-queue behavior for send/resolve/notify, which can affect scheduling and ordering across the kernel run loop, though the change is small and covered by new tests.

Overview
Fixes a kernel hang by making vat syscalls that occur outside an active crank enqueue work immediately instead of buffering it for crank completion.

Adds isInCrank() to crank methods / kernel store, and updates VatSyscall (send, resolve, and resolved-subscribe notify) to set the queue immediate flag based on !kernelStore.isInCrank(), with new unit tests covering both the new API and out-of-crank behavior.

^{Written by Cursor Bugbot for commit 9a8f97c. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	76% ⬆️ +0.01%	6556 / 8626
🔵	Statements	75.89% ⬆️ +0.01%	6661 / 8777
🔵	Functions	73.8% ⬆️ +0.01%	1640 / 2222
🔵	Branches	75.37% 🟰 ±0%	2418 / 3208

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
packages/ocap-kernel/src/store/methods/crank.ts	100% 🟰 ±0%	93.75% 🟰 ±0%	100% 🟰 ±0%	100% 🟰 ±0%
packages/ocap-kernel/src/vats/VatSyscall.ts	100% 🟰 ±0%	95.45% 🟰 ±0%	100% 🟰 ±0%	100% 🟰 ±0%

Generated in workflow #3799 for commit 9a8f97c by the Vitest Coverage Report Action

[FUDCo]

Yup, I think this is right.