[matthewp]

What

When FixVerifier rejects a candidate fix, the workflow now goes straight back into the triage pipeline. It no longer runs the RetriageJudge a second time.

Why

#60 made rejected fixes chain into retriage(), but in practice the RetriageJudge can overrule the verifier. On withastro/astro#18625 the reporter confirmed the fix worked but pointed out a regression it introduced and suggested a change. The verifier correctly returned rejected and the bot commented "Re-evaluating whether the feedback warrants a new triage attempt." The judge then returned retriage: false ("supplementary feedback for a reviewer… the fix has been verified"), and the workflow finished with no-retriage. That outcome posts no comment and leaves the label as is, so the issue was stuck on triage: fix rejected and it looked as though the bot had stalled.

The judge decides wrong here for two reasons:

• It never sees the verdict. Its input is the conversation as loaded before the rejection comment was posted, so all it sees is "Triage complete / fix pending" followed by a comment that starts with "Confirmed…".
• Its prompt only looks for new reproduction information. Feedback like "this fix causes a regression, here's a suggested change" doesn't fit any of its criteria.

The verifier has already decided the feedback is actionable, so asking again adds nothing and can silently drop the feedback.

How

• Moved the label swap to triage: needs triage plus the this.triage(...) call out of retriage() into a new restartTriage() helper.
• retriage() still runs the judge for ordinary comments on retriageable labels, then calls restartTriage() when the judge says yes.
• The rejected branch of verifyFix() now calls restartTriage() directly.
• Changed the rejection comment to "Starting a new triage attempt with this feedback." so it describes what actually happens. The new triage run then posts its own progress comment.

Testing

• tsc --noEmit passes.
• vitest run: all 459 tests pass.
• biome check passes.