fix(ocap-kernel): quarantine unrestorable vats on kernel boot

[grypez]

Explanation

On startup the daemon replays persisted subclusters and restarts their vats, fetching each vat's code from the bundleSpec recorded in the kernel store (the #963 restore path). If a single referenced bundle no longer exists on disk (moved, deleted, or otherwise unresolvable), the fetch throws ENOENT. Because VatManager.initializeAllVats restored every vat inside one Promise.all, that single rejection aborted the entire kernel boot — one orphaned bundle reference made the whole kernel unbootable.

This PR makes restore fault-tolerant. VatManager.initializeAllVats now restores each persisted vat in isolation. A vat whose launch rejects is quarantined — skipped, with a structured warning naming the vat, its subcluster, and its bundle spec — and the rest of the kernel boots normally. The persisted record is retained, so the vat is restored automatically on a later boot if its bundle returns (no silent deletion of persisted state).

Scope

The linked issue (#964) also called for making the daemon's fatal exit observable (the real error, rendered to daemon.log, instead of [object Object] on a discarded stderr). That observability work landed separately in #966, which installs file-scoped fatal handlers in daemon-entry.ts. This PR contains only the @metamask/ocap-kernel correctness fix and is rebased on main (now including #966).

With this fix, a missing bundle no longer aborts makeKernel, so the daemon reaches its normal init path and boots successfully rather than leaving a wedged process.

Test plan

• New VatManager.test.ts cases: a persisted vat whose launch rejects is quarantined, the healthy vats still restore, and a structured warning naming the vat / subcluster / bundle is logged.
• @metamask/ocap-kernel suite passes, including the existing fix(ocap-kernel): restore IO channels for persisted subclusters #963 SubclusterManager tests.

Closes #964

🤖 Generated with Claude Code

---

Note

Medium Risk
Touches the kernel startup path in VatManager.initializeAllVats, but only adds per-vat error isolation on restore; explicit vat launch still fails fast.

Overview
Kernel boot no longer fails when one persisted vat cannot be restored (e.g. missing bundleSpec / ENOENT). VatManager.initializeAllVats now restores each vat through private #restoreVat, which catches launch failures, logs a structured warning (vat id, subcluster, source via new describeVatSource), and skips that vat while other restores still complete.

Persisted vat records are not removed on quarantine, so a vat can come back on a later boot if its bundle is available again. launchVat / runVat behavior for explicit launches is unchanged—only the bulk restore path is fault-tolerant.

Tests cover mixed healthy/unhealthy restores and warning content; CHANGELOG documents the fix.

^{Reviewed by Cursor Bugbot for commit d65f902. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	71.31% ⬇️ -0.02%	8880 / 12451
🔵	Statements	71.14% ⬇️ -0.01%	9030 / 12692
🔵	Functions	72.48% ⬆️ +0.02%	2142 / 2955
🔵	Branches	64.78% ⬇️ -0.06%	3588 / 5538

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
packages/ocap-kernel/src/vats/VatManager.ts	94.44% ⬇️ -5.56%	77.77% ⬇️ -22.23%	100% 🟰 ±0%	94.44% ⬇️ -5.56%	400-406

Generated in workflow #4544 for commit d65f902 by the Vitest Coverage Report Action