fix(engine): probe the basis short final block at its own length

[oferchen]

Stacked on #7235. This branches off fix/local-append-verify-redo because it edits the same hunk of delta_transfer.rs that #7235 changed - basing on master would only defer a guaranteed conflict in that exact hunk to merge time. Base is master, so until #7235 merges this diff also carries its four commits. I will rebase onto master the moment #7235 lands. The change under review here is the last commit only.

Problem

The local delta scan reached EOF and probed the basis's trailing short block with whatever the sliding window happened to hold. That probe can essentially never succeed, for two independent reasons.

The length. Every failed full-window probe pops one byte, so at EOF the window holds block_length - 1 bytes, while find_tail_match gates each candidate on block.len() != tail_len - the same length-equality rule as upstream's l = MIN(blength, len-offset); if (l != s->sums[i].len) continue; (match.c:222-224). Only a basis whose final block happened to be exactly block_length - 1 could even reach the strong-sum comparison.

The digest. outgoing is recorded when a byte is popped, but the rolling sum is not corrected until the next push rolls it out. At EOF there is no next push, so the digest still covers the popped byte - describing one more byte than the window holds. Even the coincidental length match above would fail on sum1/sum2.

Measured on a 292x700+400 basis with the source's last full block replaced:

	Literal	Matched
upstream 3.4.4	700	204,100
oc before	1,100	203,700

Reconstruction was byte-exact either way. Only the split moved, which is why this survived: nothing is wrong with the output, the trailing block is just re-sent as literal data that upstream matches.

Upstream's rule

Upstream reaches the short block by shrinking the window. Once offset + k >= len there is no next byte, so more is false and k decrements on every step (match.c:321, match.c:331), and the scan runs to end = len + 1 - s->sums[s->count-1].len (match.c:174) - bounded by the LAST block's length, not by blength. The window therefore narrows to exactly that block's length, which is the one width the length gate at match.c:222-224 admits, because a short final block is the only block whose recorded length is below blength.

All three lines were read against rsync-3.4.4 for this change, not carried over.

Fix

Drain the window to the basis's final block length explicitly and recompute the rolling sum over exactly those bytes, then probe once - upstream's shrinking window expressed as a single probe at the only width that can match, instead of re-probing at every intermediate width. A basis that divides evenly has no short block and stays a clean no-op.

This reuses the shape from #7239 (t354) rather than inventing a second one: the probe length comes from the basis, never from "whatever is left in the window".

Result

Same fixture, same command, upstream 3.4.4 as the oracle:

	Literal	Matched	bytes
upstream 3.4.4	700	204,100	-
oc before	1,100	203,700	identical
oc after	700	204,100	identical

Tests

The obvious fixture does not test this. A delta whose source is identical to the basis passes with or without this fix: every full block matches, so the last match clears the window exactly tail_len bytes early, the probe fires by accident, and the tail is matched either way. Measured on this same 292x700+400 geometry with an identical source - all three columns run here, the "before" one against a binary rebuilt with the fix reverted: upstream 0/204,800, oc before 0/204,800, oc after 0/204,800. The three are indistinguishable, so that fixture can discriminate nothing. That accident is the entire reason this defect looked correct for as long as it did.

So every fixture here modifies the source's last full block, which forces the scan to slide to EOF holding a full window - the case the identical-source fixture cannot produce. Content comes from a 64-bit LCG: a short-period or repeating fixture would let an unaligned window match an earlier full block by content and swallow the tail, making the test assert about the data rather than about the matcher.

Boundary widths are covered because zsync 0.6 fixed an out-of-bounds access "when processing the last block of a non-compressed download" - the degenerate widths are exactly where this family of implementations has gone wrong before.

Non-vacuity, verified by reverting the fix and re-running:

test	with fix	fix reverted
..._short_final_block_at_a_full_eof_window (292x700+400)	pass	FAIL matched 203,700 vs 204,100
..._a_single_byte_final_block (tail_len 1)	pass	FAIL matched 2,100 vs 2,101
..._a_final_block_one_byte_short (tail_len 699)	pass	FAIL matched 2,100 vs 2,799
..._no_op_when_the_basis_has_no_short_block (exact multiple)	pass	pass - correct, it is the no-op guard

The block_length - 1 case failing pre-fix is what exposed the stale-digest half of the defect: that width should have matched on length alone, and did not.

The two-slice VecDeque split is exercised throughout - the window wraps after sliding through the modified block in every fixture.

Verification

• cargo fmt --all -- --check: clean
• cargo clippy --locked --workspace --all-targets --all-features --no-deps -- -D warnings: exit 0
• cargo nextest run -p engine --all-features: 5042/5042
• cargo xtask validate --transport local: 59 passed / 3 failed / 3 skipped. The three failures are the pre-existing verbosity: local -v/-vv/-vvv - line 1: oc "a.txt" vs upstream "./" divergence, unrelated and unchanged by this PR. whole-file: local delta, whole-file: local whole and all three append-inplace cells pass.