Forwarded replication operations leak requestId into the operation body, breaking replicated set_configuration #969

Summary

When a node forwards an operation to a peer over replication, the RPC correlation id requestId stays in the operation body that the peer passes to server.operation. Operations that validate their body strictly then see an unknown requestId key. Replicated set_configuration is the reported case: it is rejected on the peer on current main.

Mechanism (harper-pro main @ 36efd7e4)

• Sender, sendOperation (replication/replicationConnection.ts ~8572): operation.requestId = requestId; mutates the caller's operation object and sends it as [OPERATION_REQUEST, operation].
• Receiver, OPERATION_REQUEST handler (~4929): server.operation(data, { user: authorization }, …) receives data with requestId still attached. The reply paths then read data.requestId (~4936, 4940, 4945, 4949) to correlate the response.

So requestId is transport metadata that ends up in the operation payload. Any operation whose validation rejects unknown properties fails on the remote node. Every other forwarded operation silently receives an extra field.

This was found during review of harper-pro#956 (table-drop recovery), and the agent's investigation reported it as pre-existing, independent of that PR. The set_configuration rejection was reported by that investigation and has not been independently reproduced here.

Proposed fix

Treat requestId as envelope, not payload:

• On send, do not mutate the caller's operation. Send the id beside it, or strip it into the frame.
• On receive, capture requestId before dispatch, pass server.operation a body without it, and restore it on every reply path (success, encoding failure, operation rejection, synchronous throw) from the captured value instead of data.requestId.

Keep wire compatibility with peers on the old shape. An old sender still embeds requestId in the body, so the receiver should strip it there too. An old receiver still expects it in the body.

Tests

• Two-node integration test: replicated set_configuration succeeds on the peer and the configuration propagates.
• Reply/error correlation: concurrent forwarded operations, including one that fails validation, each resolve to their own response.
• Mixed-version: an old-shape request (id in the body) is still answered and correlated.