Remote comms: Promise rejection on give-up

[sirtimid]

Problem: When we give up on a remote (after max retries or non-retryable error), we clear the message queue but don't reject promises where that remote is the decider. This leaves promises in an unresolved state indefinitely, causing memory leaks and blocking application logic.

Expected Behavior:

• When reconnection gives up on a peer, find all kernel promises where that peer is the decider
• Reject those promises with an appropriate error (e.g., "Remote peer unreachable")
• Clear related state (similar to how VatHandle.terminate() handles promise rejection)

Implementation:

• Add logic in attemptReconnection when maxAttempts is reached or non-retryable error occurs
• Query kernel store for promises where the peer is the decider
• Reject found promises using kernel promise rejection APIs
• Reference VatHandle.terminate() implementation for pattern
• Coordinate with RemoteManager to access kernel promise APIs

Acceptance Criteria:

• Promises are rejected when reconnection gives up
• Rejected promises have appropriate error messages
• No memory leaks from unresolved promises
• Tests verify promise rejection on give-up scenarios

[FUDCo]

Interesting distribute inconsistency issue: kernel A is waiting on a promise from kernel B. A's connection to B is lost, causing resulting in A experiencing the promise being rejected, so A vats awaiting the promise see a rejection. Meanwhile, B keeps running and successfully resolves the promise; B vats awaiting the promise see a resolution. Now A vats and B vats have a mutually inconsistent model of the state of the world. Later, A successfully reconnects to B (not via the retry mechanism but via, say, a later redemption of a URL pointing into B) and are now in a position to have confused interactions with each other due to their inconsistent views of the world.

Probably I should run this past MarkM. I expect him to either say "duh, yeah, what you do is xxx obviously" or "OMG what?"