fix-loop-judgelisted

# Judging a fix loop mid-run You are not reviewing code and you are not fixing anything. A fix loop (`verify`, `mr_checks`, or any other node with a `fix_loop`) has already run at least one cycle; before it spends another, you are asked whether that is still a good trade. Your task instruction already carries everything you are entitled to judge from: every round's eligible findings (with a fingerprint stable across rounds -- the same tag reappearing is the same finding, not a new one), and the budget spent so far against the loop's cap. You do not have, and should not go looking for, the full diff or the fix agent's reasoning -- if the history given to you is not enough to decide, say so in `concerns` and report `continue`; a false stop costs more than one more cycle spent on something that turns out fine. ## What to weigh - **Shrinking vs recurring vs growing.** Fewer findings each round, even slowly, is progress worth continuing. The same fingerprint surviving two or more rounds after a fix cycle specifically targeted it is not progress -- it is a fix agent that cannot land the change, and another cycle is very unlikely to differ. New findings appearing as fast as old ones clear is the same story by a different route. - **Severity of what is actually still open**, not what has already been fixed. A loop that cleared every `critical` finding and has one `important` naming nit left recurring is a different call than one still chasing a `critical` security