[lmtlssss]

Failure

After backup.py starts against a remote SocketBackend that is one uncommitted database write ahead, check_first_write invokes SocketBackend.rewind(). The socket server sends an ACK containing its resulting version, but the client discards that payload and retains its old version and prev_version.

If the replacement write is interrupted before the server stores it, add_change() reconnects and reads the correct rewound server version. It compares that version to the stale client baseline, raises Unexpected backup version, and cannot retry the valid replacement. This is a backup availability/recovery bug during a real startup crash window; production incidence and funds exposure are not established.

Change

• Require the rewind ACK's version to equal the requested target.
• Update the client's version to the acknowledged server version and reset its prior-version marker before the replacement write.
• Leave the normal successful-append and post-ack-lost idempotent reconnect paths unchanged.

Evidence and limits

A prospective source-level regression contract was recorded before editing. In an isolated Python transport-method replay using the inspected upstream rewind, _request_metadata, and add_change logic, original handling failed after a successful rewind; with the candidate, both cases pass: (1) interrupted before server persistence and (2) server persisted but ACK was lost. A mismatched ACK is rejected and ordinary append bookkeeping remains correct.

The PR includes 3 focused synthetic-transport pytest cases in backup/test_socket_rewind.py. These and the full plugin test suite still require execution against the exact checked-out source; the isolated replay is not a full SocketServer/FileBackend, backup-cli, lightningd, durability or channel-recovery qualification. No production deployment or demonstrated funds loss. Please keep DRAFT pending native test and maintainer integration review.

This is independent of submitted backup-file rewind #1018 and staged database restore #1019.