test(transfer): pin the verify-failure name and the format-derived gate

[oferchen]

Tests only. No production change - both halves of #352 measure already
correct on the path that emits the diagnostic. What they were missing is a test
in the dimension that would catch a regression.

Measured first, against rsync 3.4.4

Forced a real verification failure the way upstream's own --append-verify
does: the destination holds a wrong 100 KiB prefix under a 200 KiB source, so
the whole-file checksum fails and a phase-2 redo follows. File nested at
sub/deep/payload.bin.

Upstream prints the same name on every transport, so there is no per-transport
answer:

cell	upstream 3.4.4	oc @ master
local, relative dest	sub/deep/payload.bin	(no warning - see below)
local, ABSOLUTE dest	sub/deep/payload.bin	(no warning)
remote-shell push, relative dest	sub/deep/payload.bin	sub/deep/payload.bin
remote-shell push, ABSOLUTE dest	sub/deep/payload.bin	sub/deep/payload.bin
remote-shell pull	sub/deep/payload.bin	sub/deep/payload.bin

Every cell recovered byte-correctly on both binaries. The gate matches too:

verbosity	upstream	oc
default	silent	silent
-v	1 warning	1 warning
-i (no -v)	1 warning	1 warning
--out-format=%i%n (no -v, no -i)	1 warning	1 warning

The local cell is silent because the local-copy emit site is #7235, not merged.
That is an absence, not an absolute-path defect.

What was unpinned

Every existing cell in this file uses a FLAT payload.bin, where three
different renderings collapse to one string: the flist name, the basename, and a
name relativised against the wrong root. A rendering that dropped the directory
prefix would pass all of them.

And the gate was pinned only for default-silent and -v. The input that
actually separates the two possible implementations - a format carrying %i
with no -i - was untested.

The two cells

Nested name. Uses both discriminators at once: a nested file, and an
ABSOLUTE destination operand. Upstream change_dir()s into the destination root
(main.c:815) so fname at receiver.c:1089 is the file-list name however the
operand was written; oc joins a destination root to reach the file on disk, so
the absolute path is the value most readily to hand. The absolute operand is
where a joined path leaks and nowhere else.

Format-derived gate. options.c:2345-2358 feeds stdout_format_has_i from
two sources, and -i REWRITES stdout_format to "%i %n%L":

if (stdout_format) {
        if (am_server && log_format_has(stdout_format, 'I'))  stdout_format_has_i = 2;
        else if (log_format_has(stdout_format, 'i'))          stdout_format_has_i = itemize_changes | 1;
} else if (itemize_changes) {
        stdout_format = "%i %n%L";
        stdout_format_has_i = itemize_changes;
}

So --out-format='%i%n' with no -i and no -v still enables the warning. A
gate implemented as "did the user pass -i" is silent there.

Proven red

Each mutation turns red its own cell and only its own:

mutation	nested cell	gate cell
name the joined destination instead of the flist name	FAIL	pass
force the format-derived disjunct to false	pass	FAIL

A gate defect found while doing that

test_support::oc_rsync_bin() resolves target/debug/oc-rsync at runtime;
it is not env!("CARGO_BIN_EXE_oc-rsync"). These integration tests therefore
carry no build dependency on the binary they exercise - a mutation whose
link step fails leaves the previous binary in place and the test still passes.

That is not hypothetical: my first mutation run reported green against an
OOM-killed link, and I only caught it because the standalone build reported
exit 101 while the test reported success. Every mutation result above was
re-taken after confirming cargo build --bin oc-rsync exited 0. Filed
separately - it makes this whole test family capable of validating a stale
binary.

Verification

cargo nextest run -p transfer --all-features -E 'test(nested_flist_name) or test(gate_reads_the_output_format)' - 2 passed, on a tree confirmed free of
both mutations. Exit codes read directly, never through a pipe. GitHub Actions
has not validated this; it is not scheduling.