fix(ocap-kernel): boot past a vat whose code can no longer be loaded

[grypez]

Third of three, stacked on #1030. This is the fix for the issue #1025 was opened
for; the two beneath it are bugs reachable on main today that #1025 had to fix
in order for this one to be an improvement rather than a worse failure mode.

The defect

A vat outlives the code it was launched from. The kernel stores a vat's durable
state but not its code, re-fetching from the recorded bundleSpec on every
incarnation — so a bundle that is rebuilt to a new path, pruned, or recorded as
an absolute path that did not survive relocation leaves a persisted vat that
cannot be restored.

VatManager.initializeAllVats restored every vat inside one Promise.all, so
one such vat rejected out of Kernel.#init, Kernel.make rejected, and the
whole kernel — every healthy subcluster included — was unbootable. Under the
daemon that surfaced only as "Daemon did not start within 30s".

Approach

Each vat is restored in isolation. The one that fails is skipped and the rest of
the kernel boots.

Its record is kept, not pruned, so a vat whose code becomes reachable again
is restored by a later boot, resuming from the durable state it left off with.
Discarding persisted state is not a call the restore path gets to make, and a
missing bundle is usually a build or packaging problem rather than a decision
about the vat.

The leftover worker is reaped. A bundle is fetched inside the vat's own
worker (VatSupervisor.#initVat → fetchBlob), so by the time the load fails
launch has long since resolved and the worker is live; one left behind is the
wedged process holding the sqlite lock that this failure mode is known by. When
launch itself was what failed there is no worker to reap, so that is logged at
debug.

An error names the vat, its subcluster, and its code source. Trading an
unbootable kernel for one that is quietly missing a vat would be no trade at
all.

Scope

Deliberately not decided here: whether an unrestorable vat should take its
whole subcluster down with it. That is the coterminous-lifecycle question in
#979, and the tests are written so no lifecycle policy is presumed — the
unrestorable vat sits in a different subcluster from the healthy one, so no
policy under discussion makes the healthy vat's loss correct.

Worth being precise about what a skipped vat is, since the changelog wording
invites a stronger reading than the code supports. Its data is preserved; its
interactions are not. Promises it was already deciding stay unresolved forever,
but new sends to it are rejected immediately with ENDPOINT_UNREACHABLE,
notifications owed to it are dropped, and GC actions against it still perform
the kernel's own half. What comes back on the day the bundle returns is not
what left. Making a skipped vat genuinely resumable is a lifecycle decision and
belongs with #979.

restartVat also cannot recover one without a kernel restart, since it requires
a running vat.

The observability half of #964 (rendering the real fatal to daemon.log rather
than [object Object] on a discarded stderr) landed separately in #966.
fetchBlob needs no change: Node's errno already carries the path, and the
[object Object] came from the error crossing the worker's JSON-RPC boundary.

Testing

First commit is the failing repro on its own, at three layers.

• Kernel.test.ts — boot completes with the healthy vat up and the
  unrestorable one absent, and one error entry names both the vat and its bundle.
• VatManager.test.ts — both failure timings (before the worker comes up,
  and after it is live, which is the production one); the reap takes only the
  failed vat's worker; boot survives a reap that cannot happen; the record is
  not pruned; all three VatConfig source shapes and the no-subcluster
  fallback; and several unrestorable vats at once, the case that cannot be
  satisfied by catching around the whole batch.
• kernel-test/persistence.test.ts — the real path end to end: real
  bundles, real workers, a real file deleted between two real incarnations, and
  the genuine fetchBlob ENOENT arriving from inside the worker. A vat whose
  bundle returns comes back with the state it left off with; and one whose
  subcluster was torn down while it was skipped stays gone when its bundle
  returns, rather than reappearing in a subcluster that no longer exists and
  failing every getStatus thereafter.

@metamask/ocap-kernel and @ocap/kernel-test green, with auditRefCounts on
for every kernel kernel-test builds. lint and build clean.

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed, highlighting breaking changes as necessary
• I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	72.64% ⬆️ +0.10%	9738 / 13405
🔵	Statements	72.49% ⬆️ +0.09%	9901 / 13657
🔵	Functions	73.11% ⬆️ +0.12%	2284 / 3124
🔵	Branches	67.05% ⬆️ +0.16%	4016 / 5989

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
packages/ocap-kernel/src/vats/VatManager.ts	100% 🟰 ±0%	100% 🟰 ±0%	100% 🟰 ±0%	100% 🟰 ±0%

Generated in workflow #4696 for commit 81acebb by the Vitest Coverage Report Action