test(ocap-kernel): pin the release failure lost at the remote savepoint

Failing repro, not a fix.

## The issue

#1012 hardens `releaseSavepoint` so that a failed `RELEASE` discards the
enclosing transaction, clearing the driver's `_spStack` on the way. Two callers
it does not touch depend on the old behaviour, and both are now worse off than
before the change.

`RemoteHandle.handleRemoteMessage` releases inside the `try` and rolls back in
the `catch`:

    this.#kernelStore.setRemoteHighestReceivedSeq(this.remoteId, seq);
    this.#kernelStore.releaseSavepoint(savepointName);   // fails
  } catch (error) {
    this.#kernelStore.rollbackSavepoint(savepointName);  // "No such savepoint"
    throw error;                                        // never reached
  }

Since the release already cleared the stack, the rollback throws
`No such savepoint: receive_r0_1`, which escapes the `catch` and replaces the
real failure. Not demoted to `cause` — replaced. `RemoteManager` has the same
shape at its `peerIncarnation_*` savepoint.

A/B verified against origin/main with a real driver: main's rollback succeeds
and `database or disk is full` propagates; on this branch the caller gets the
missing-savepoint error instead. So the PR description's "the release failure
still propagates" holds for the crank path it fixed and not for these two.

`crank.ts:57-63` shows the author recognised exactly this hazard — a stale
savepoint list producing `No such savepoint` over the real error — and fixed it
for the crank only. The remote paths were missed because nothing exercised them.

Note the secondary effect these tests don't reach: `ctx.savepoints` still lists
the crank's own savepoints after this, so the next `endCrank` throws
`No such savepoint: t0` over whatever is left of the failure.

## What we hope to see instead

The failure the database reported is what reaches the caller. Any of these does
it, and the assertion doesn't care which:

- move the release out of the `try`, so a release failure isn't followed by a
  rollback attempt at all
- have the `catch` tolerate a rollback that reports a savepoint already
  discarded, rethrowing the original either way
- make the driver's discard leave the name rollback-able as a no-op

The mock models the drivers' bookkeeping rather than the expected outcome, so it
is `RemoteHandle`'s error handling under test, not the mock's.

## Current failure

    AssertionError: expected Error: No such savepoint: receive_r0_1
      to be Error: database or disk is full
      packages/ocap-kernel/src/remotes/kernel/RemoteHandle.test.ts
      > reports the release failure rather than a missing savepoint

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

Author: 2 people

packages/ocap-kernel/src/remotes/kernel/RemoteHandle.test.ts

@@ -220,6 +220,49 @@ describe('RemoteHandle', () => {
       });
     });
 
+    // FAILING REPRO — see the commit message for this test.
+    //
+    // `handleRemoteMessage` releases its savepoint inside the `try` and rolls
+    // back in the `catch`. #1012 made a failed `RELEASE` discard the whole
+    // savepoint stack, so that rollback now reports a savepoint that no longer
+    // exists, and it throws out of the `catch` in place of the failure that
+    // brought it there.
+    it('reports the release failure rather than a missing savepoint', async () => {
+      // The drivers' bookkeeping as #1012 leaves it, verified against both: a
+      // failed RELEASE clears `_spStack`, and rolling back a name that is not on
+      // it throws `No such savepoint`.
+      const savepoints: string[] = [];
+      const releaseFailure = new Error('database or disk is full');
+      mockKernelStore = {
+        ...mockKernelStore,
+        createSavepoint: (name: string) => {
+          savepoints.push(name);
+        },
+        releaseSavepoint: () => {
+          savepoints.length = 0;
+          throw releaseFailure;
+        },
+        rollbackSavepoint: (name: string) => {
+          if (!savepoints.includes(name)) {
+            throw new Error(`No such savepoint: ${name}`);
+          }
+        },
+      } as KernelStore;
+      const remote = makeRemote();
+
+      const delivery = JSON.stringify({
+        seq: 1,
+        method: 'deliver',
+        params: ['bringOutYourDead'],
+      });
+
+      // The error an operator needs is the one the database gave, not the
+      // bookkeeping artefact of trying to clean up after it.
+      await expect(remote.handleRemoteMessage(delivery)).rejects.toBe(
+        releaseFailure,
+      );
+    });
+
     // A dead run loop will never deliver the message, and `handleRemoteMessage`
     // rolls back without advancing the received sequence number, so the peer
     // retries and gives up rather than being acknowledged by a black hole.