Proposed fixes repeatedly mis-target the root cause; residual stays open across many attempts

A small residual (a handful of cases out of ~100) has stayed open across many attempts and several distinct proposed solutions, because each proposed fix was aimed at a hypothesized cause that turned out to be wrong when the underlying data was actually read.

Concrete pattern this turn:

• A 'value-ordering mismatch' was diagnosed and a fix proposed: sort both sides' inputs to a canonical order before comparison.
• Reading the actual captured reference data showed the reference was ALREADY in canonical order — so the proposed sort is a no-op and could never have fixed it. The true misalignment is elsewhere (the consuming/comparison layer), not where the fix was aimed.
• This is the same shape as earlier turns: a plausible cause is asserted, a fix is built around it, and only after applying + re-verifying (a full expensive cycle) does reading the data reveal the cause was mis-located.

Net effect: the agent (and the user guiding it) keep proposing and applying fixes that cannot work because the root cause was inferred rather than read first, burning a verify cycle each time, and the residual never closes.

Requests:

1. Before proposing OR applying a fix, the agent must READ the actual artifact that proves the cause (the data/file/output), not infer it — especially after a prior fix already failed. 'Read the file, then fix' must precede 'fix, then verify'.
2. When a proposed fix is shown to be a no-op against the real data (as here), say so immediately and do not spend a verification cycle on it.
3. After several mis-targeted fixes on the same residual, stop, state the residual honestly, and escalate rather than continuing to bill the user for more attempts.