test(xtask): compare verify-redo warnings per stream

[oferchen]

Stacked on #7232 (base test/xtask-verify-redo-check). Draft until #7232 lands.

The hole

warning_lines() was only ever called with the two stderr captures:

let up_warnings = warning_lines(&up_err);
let oc_warnings = warning_lines(&oc_err);

Assertion 3 therefore could not see a line on stdout. Measured on macOS against rsync 3.4.4, using the check's own fixture and flags, with stdout and stderr captured to separate files:

cell	verbosity	upstream stdout	upstream stderr	oc stdout	oc stderr
local pull	default	-	-	-	-
local pull	-v	-	WARNING: payload.bin ...	-	-
daemon pull	default	-	-	WARNING: <absolute path>/payload.bin ...	-
daemon pull	-v	-	WARNING: payload.bin ...	WARNING: <absolute path>/payload.bin ...	-
daemon push	default	-	-	-	-
daemon push	-v	-	WARNING: payload.bin ...	-	WARNING: payload.bin ...

The daemon-pull default cell is the vacuous pass: upstream prints nothing anywhere, oc prints an ungated line carrying an absolute path on stdout, and comparing [] == [] accepted it. Today a later assertion catches that cell on the delta split, so the divergence is merely misattributed; once the in-flight delta fixes land it would go green while still diverging. The -v cell was worse than useless - it reported oc [] != upstream [...], which reads as "oc printed nothing" when oc printed on the wrong stream.

The ssh cells are not in the table: no sshd answers on localhost:22 here, so the check skips them. Only the cells where oc is the receiver exercise oc's own emit; on daemon push the receiver is the upstream peer.

The fix

Capture per stream and compare stdout and stderr separately. The oracle becomes a pair:

• default: absent from both streams (upstream: receiver.c:1072 gates the line behind INFO_GTE(NAME, 1)).
• -v: present on stderr, absent from stdout (upstream: rwrite() maps FWARNING to f = stderr, log.c:314, and forwards it as MSG_WARNING when am_server).

The failure message names the stream, because the text is identical wherever it lands. Nothing else in the check changes: the oracle values (2 transfers, Literal 205,300, Matched 101,900) were re-measured against live upstream and are untouched, and no assertion was relaxed.

Before / after

cargo xtask validate --transport local --transport daemon, same master oc binary both runs.

Before:

  [FAIL] local pull verbose - warning lines: oc [] != upstream ["WARNING: payload.bin failed verification -- update retained (will try again)."]
  [FAIL] daemon pull default - Literal data: oc=307200 upstream=205300
  [FAIL] daemon pull verbose - warning lines: oc [] != upstream ["WARNING: payload.bin failed verification -- update retained (will try again)."]

After:

  [FAIL] local pull verbose - warning lines: stderr: oc [] != upstream ["WARNING: payload.bin failed verification -- update retained (will try again)."]
  [FAIL] daemon pull default - warning lines: stdout: oc ["WARNING: /abs/.../payload.bin failed verification -- update retained (will try again)."] != upstream []; oc wrote the line to stdout; upstream never does
  [FAIL] daemon pull verbose - warning lines: stdout: oc [...] != upstream []; stderr: oc [] != upstream ["WARNING: payload.bin ..."]; oc wrote the line to stdout; upstream never does

The daemon-pull-default cell moving from a delta-split failure to a named stream failure is the proof: assertion 3 now fires where it previously passed on nothing. These cells are expected to stay red until the emit-site and delta fixes land.

Verification

• cargo fmt --all -- --check clean
• cargo clippy --locked --workspace --all-targets --all-features --no-deps -- -D warnings clean
• cargo nextest run -p xtask --all-features -E 'test(verify_redo)' - 10 passed