Redeeming an ocap URL for a revoked object allocates c-list state

[sirtimid]

redeemLocalOcapURL (packages/ocap-kernel/src/remotes/kernel/remote-comms.ts:339-356) decrypts the URL, asserts the reference is well-formed, and returns the kref. It does not check whether the object has been revoked.

RemoteHandle.#handleRedeemURLRequest (:869-886) then calls translateRefKtoE(remoteId, kref, true), which allocates a c-list entry and increments the refcount for a revoked object.

Three consequences:

1. The refcount is pinned, so the revoked object cannot be collected.
2. A holder of a stale URL can repeatedly force c-list growth.
3. Redemption succeeding tells the holder the object exists, even though every subsequent message to it will fail. That is an existence oracle for something they no longer have authority over.

Proposed: check isRevoked in redeemLocalOcapURL and fail the redemption before any translation or allocation occurs. The failure should be indistinguishable from redeeming a URL that never referred to anything (see the error-uniformity issue).