Remote comms: Message Acknowledgment and Retransmission

[sirtimid]

Problem: Currently, sendRemoteMessage() uses a fire-and-forget model. Messages are queued during reconnection and flushed afterward, but there's no way to know if messages were actually received. This causes message loss when connections drop mid-transmission, and makes it impossible to guarantee delivery of critical messages like promise notifications (deliverNotify()).

Expected Behavior:

• Add unique message IDs to all outgoing messages
• Implement ACK message type in the protocol (add to deliver method cases)
• Track pending messages awaiting ACK per peer
• Retransmit messages if ACK not received within 10 seconds (up to 3 retries)
• Update sendRemoteMessage() to return a promise that resolves on ACK or rejects after retries exhausted
• Coordinate with existing message queueing during reconnection (retry un-ACKed messages after reconnect)

Implementation:

• Add message ID generation (per-peer sequence or UUID)
• Wrap messages with ID: { id: string, message: string }
• Add ack message type to protocol handler in RemoteHandle.handleRemoteMessage()
• Track pending messages in network.ts (Map<peerId, Map<messageId, PendingMessage>>)
• Add timeout logic: if ACK not received in 10s, retransmit (max 3 times)
• Coordinate with existing message queueing: track ACK status of queued messages, only retry un-ACKed messages after reconnection
• After reconnection, retransmit un-ACKed messages before flushing new queued ones
• Update SendRemoteMessage type to return Promise<void> (already does, but document it resolves on ACK)
• Consider interaction with rate limiting (Remote comms: Basic Rate Limiting #661) - retransmissions should be counted separately or exempted

Acceptance Criteria:

• All messages have unique IDs
• ACK messages are sent and processed correctly
• Messages are retransmitted if ACK not received (10s timeout, 3 retries)
• sendRemoteMessage() promise resolves on ACK or rejects after retries
• Un-ACKed messages are retransmitted after reconnection
• Tests verify ACK/retry behavior and reconnection scenarios

Note: This supersedes Issue #662 (Fix Promise Resolution Tracking) for promise notifications. If implemented, #662 can use this general ACK mechanism instead of separate promise notification tracking.