fix(reliability): bound empty assistant output retries

[0xMink]

Refs #10322

Summary

• Bound auto-retry when the model returns no text and no tool calls (empty/malformed/reasoning-only output) by routing repeated empty outputs into the existing mistake-limit mechanism
• Preserve grace retry behavior; from the second consecutive empty output onward, emit MODEL_NO_ASSISTANT_MESSAGES and increment consecutiveMistakeCount
• Refactor: extract onEmptyAssistantOutput() and onNoToolUse() helpers to keep retry accounting consistent and testable

Test plan

• Existing: pnpm exec vitest run core/task/__tests__/Task.spec.ts — 38 passed, 4 skipped
• New: pnpm exec vitest run core/task/__tests__/grace-retry-errors.spec.ts — 14 passed (3 new tests call production helpers via (task as any).onEmptyAssistantOutput() / onNoToolUse())

---

Important

Integrates repeated empty assistant outputs into the mistake-limit mechanism and refactors for consistent retry handling in Task, with new tests added.

• Behavior:
  • Integrates repeated empty assistant outputs into the mistake-limit mechanism in Task.
  • Emits MODEL_NO_ASSISTANT_MESSAGES and increments consecutiveMistakeCount from the second consecutive empty output.
• Refactor:
  • Extracts onEmptyAssistantOutput() and onNoToolUse() in Task for consistent retry accounting.
• Tests:
  • Adds tests in grace-retry-errors.spec.ts for new behavior, including onEmptyAssistantOutput() and onNoToolUse().
  • Confirms counters reset on success and increment independently for different error types.

^{This description was created by for 15a40c4. You can customize this summary. It will automatically update as commits are pushed.}

[roomote]

Rooviewer   See task

All previously flagged issues have been addressed. No new issues found.

• ConsecutiveMistakeError reason at line ~2732 hardcodes "no_tools_used" but now the limit can also be reached via empty assistant outputs -- telemetry reason should distinguish the two paths

Previous reviews

• 51e9866: Review #1
• 15a40c4: Review #2

_{Mention @roomote in a comment to request specific changes to this pull request or fix all unresolved issues.}

[roomote]

Now that this path also increments consecutiveMistakeCount, the ConsecutiveMistakeError at line ~2732 will report "no_tools_used" as the reason even when the limit was reached via repeated empty assistant outputs. The comment at lines 2723-2724 ("The reason is 'no_tools_used' because this limit is reached via initiateTaskLoop") is also stale. Low severity since it only affects telemetry accuracy, but worth updating the reason to distinguish between the two error paths so dashboards/alerts can differentiate them.

_{Fix it with Roo Code or mention @roomote and request a fix.}

[0xMink]

Addressed in 51e9866. Telemetry now records the actual trigger (no_tools_used vs no_assistant_messages) via a consecutiveMistakeReason field set at the increment site and passed through to ConsecutiveMistakeError. Reason resets to "unknown" when the mistake count resets. Two new tests verify the reason is set correctly for each path.