feat(ocap-kernel): keep a GC action a remote could not be told about

[sirtimid]

Stacked on #1098. Its own diff is
git diff sirtimid/endpoint-lookup-and-skip...sirtimid/remote-gc-delivery-refused.

The kernel releases its own side of a GC action — clears the reachable flag, or
deletes the c-list entry — before telling the endpoint, because telling an
endpoint to let go is also the kernel letting go. For a vat that refuses, the
crank aborts and the vat is terminated: a local vat that cannot take a GC
delivery is broken. For a remote there is no such answer, and #1022 chose to log
and commit the release anyway, on the grounds that retrying starves the kernel.

The cost of that, found in review and filed as #1064: the peer still holds the
eref. Its next message naming it goes through exportFromEndpoint and mints a
second kref for the same object, and nothing reconciles that until an
incarnation change — for a retireImports, not even then, since
forgetEndpointImports keeps only entries whose direction is export. #1017
describes the frame-flipping half of the same picture.

This is option 1 of the three in the design note: abort and keep the action,
and take remote GC actions off the front of the queue. The crank aborts, which
restores the action and the c-list entries together, and that remote's actions
are held back from selection until the run loop next has nothing else to do.
Holding them back is what makes aborting affordable: processGCActionSet is
consulted before every other source of work, so re-selecting a failing action
every crank would starve the kernel to serve one unreachable peer. Waking from
an empty queue is both the bound on the wait and the moment when retrying costs
nobody anything.

The same treatment covers a remote the kernel has no handle for at all, which is
every remote until the embedder calls initRemoteComms. #1098, below this one,
deliberately left that case loud rather than dropping what it carried; this is
where it gets somewhere to wait instead.

A note on the merge in this branch

sirtimid/crank-rollback-reverts-caches (#1087) is merged in, because aborting
only keeps the action if rollbackCrank reverts the cached gcActions set as
well as the database row. Without it the abort restores the row, the live kernel
goes on reading the spent set, and the next write erases the row too — the
feature is inert. Three reviewers found this independently and the real-store
test below fails without it. The merge disappears from this diff once #1087
lands on main.

Changes

• processGCActionSet takes an isHeldBack predicate. A held-back endpoint's
  actions are not examined at all, which is what keeps them: an action merely
  examined is deleted from the durable set whether or not it is selected.
• KernelQueue.holdBackRemoteGC and #remotesHeldBack, cleared when the run
  loop wakes from an empty queue.
• KernelRouter.#deliverGCAction aborts and holds the remote back, for a remote
  that refuses the delivery and for one it has no handle for. A vat is
  unchanged.
• @metamask/ocap-kernel changelog entry under Fixed.

Testing

KernelRouter.remote-gc.test.ts is the end-to-end one, against a real nodejs
SQLite :memory: store and the real run loop: a remote refuses a
retireImports, and afterwards both the action and the c-list entry are still
there. Removing the crank's cache revert fails it with
expected [] to strictly equal [ 'r1 retireImport ko1' ], which is what the
merge above exists for.

KernelRouter.test.ts covers the three action types against an unreachable
remote — { abort: true }, nothing released, the remote held back — the refused
delivery, and a vat that refuses still throwing. garbage-collection.test.ts
covers the predicate: the other endpoints' work is given instead, the held-back
endpoint's actions stay in the durable set, and it gets its turn once nothing
holds it back. KernelQueue.test.ts pins the bound, with a crank of ordinary
work before the queue empties so that clearing after every crank — which is a
livelock — no longer passes.

Six mutations checked in all. Full @metamask/ocap-kernel suite green locally;
eslint, constraints and changelog:validate clean.

Not addressed here, and worth its own change: a held-back remote is not visible
in KernelStatus, and nothing lifts the hold when the remote reconnects — only
an idle run loop does. A remote that never comes back is retried whenever the
kernel is idle, forever, with a warning each time.

Closes #1064

🤖 Generated with Claude Code

---

Note

High Risk
Changes distributed GC delivery, crank abort/rollback, and in-memory store cache consistency—core run-loop paths where mistakes can desynchronize peers or kill the kernel.

Overview
Fixes remote garbage collection so the kernel no longer commits its side of a release when the peer was never told, which could leave the remote holding stale erefs and mint duplicate krefs on the next message.

When a remote has no handle yet or refuses a GC delivery, KernelRouter now returns { abort: true } (via #keepForLater) instead of dropping the action or committing after a failed send. The crank rollback restores the spent GC action and c-list state together. Local vats that refuse still throw and terminate as before.

To keep retries from starving the run loop (GC actions are picked before all other work), processGCActionSet accepts an isHeldBack predicate, KernelQueue tracks #remotesHeldBack, and held remotes are skipped until the loop parks on an empty queue and clears the set.

The same branch includes crank/store fixes needed for abort to work: rollbackCrank reverts in-memory caches (refreshCachedValues) and restores maybeFreeKrefs from savepoint snapshots; clear/reset call discardCachedState so stale run-queue heads cannot kill the next crank.

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