[bug] verify evidence keeps the head of long output, dropping the error the repair loop needs #64

Summary

When verify output is longer than the evidence cap, the stored output keeps the start and drops the end. For Cargo, the start is compile progress and the end is the error. The repair loop then annotates the wrong part of the output, finds nothing to fix, and stops. The reviewer can't see the failure either.

Version / OS

meshloop built from 09a823a (0.3.0). Windows 11 native.

Observed

Graph issues-46-47-56 (PR #63), node 1, attempt 3. verify_command ran cargo run -p xtask -- check, which failed in clippy (error: duplicated attribute --> crates\meshloop-cli\tests\plan_and_run.rs:1414:1).

• The stored pwsh evidence row contained only Running cargo fmt …, Running cargo check … and then about 50 Compiling … lines, cut off mid-line. The clippy error wasn't in it.
• The repair-session row recorded lattice=… syntax=0 type=0 test=0 blocking=0, rounds=1, action=Accept passed=false. The repair loop saw no diagnostics, so it never tried a repair.
• Finding the cause meant re-running clippy by hand in the kept worktree.

Nodes 2 and 3 failed the same way, on cargo fmt --check and clippy::too_many_arguments respectively.

Expected

• When output has to be shortened, keep the end, or keep the start and end with a marker in between. Record that it was truncated and the original size.
• Before shortening, pull out diagnostic lines (error:, warning:, -->, FAILED, panicked) so the repair loop and the reviewer always see them.
• Larger output can go to a redacted log file on disk, with its path in the evidence row, as runtime-design.md §4 allows.

Acceptance criteria

• Test: a check whose output is about 50 KB of noise followed by an error: line → the stored evidence contains the error: line and a truncation marker.
• Test: the repair loop's diagnostic lattice for that evidence has blocking > 0.

🤖 Generated with Claude Code