Add message sequencing and acknowledgment to remote messaging

[FUDCo]

Implements message acknowledgment and retransmission.

• Updates RemoteCommand type to include seq (sequence number) and ack (piggybacked ACK) fields
• Per-peer sequence tracking that persists across reconnections
• Implements timeout/retry logic with promise-based tracking

Closes #656

---

Note

Implements message sequencing and acknowledgment across remote comms, refactors per‑peer state, and updates the messaging API to send structured objects instead of strings.

• Add seq/ack handling: RemoteHandle parses seq/ack, calls updateReceivedSeq and handleAck before processing; RemoteMessageBase exported and used throughout
• New per‑peer state via PeerConnectionState (tracks next/received seq, pending MessageQueue, ACK processing, and rejection on close/stop)
• Refactor MessageQueue to store PendingMessage objects, add peekFirst, return boolean on enqueue, and reject when at capacity (no dropping)
• API changes: Kernel.sendRemoteMessage and RemoteManager.sendRemoteMessage now accept RemoteMessageBase (object), with RemoteManager forwarding via platformServices
• Update tests extensively to the new protocol and API (auto‑ACK helpers, object messages, seq/ack assertions); direct test platform adds no‑op handleAck/updateReceivedSeq

^{Written by Cursor Bugbot for commit 74790e7. This will update automatically on new commits. Configure here.}

[cursor]

Message sent but promise rejected when queue at capacity

Medium Severity

The addPendingMessage method ignores the return value of MessageQueue.enqueue(), which returns false and rejects the pending promise when the queue is at capacity. In sendWithAck, after calling addPendingMessage, the code continues to send the message over the network regardless of whether it was actually added to the pending queue. This causes inconsistent behavior: the sender's promise is rejected (indicating failure), but the message is actually transmitted successfully. The message won't be tracked for ACK, potentially causing ACK tracking to get out of sync and misleading the caller about delivery status.

Additional Locations (1)

• packages/ocap-kernel/src/remotes/network.ts#L306-L307