fix(processor): detect doom loops across messages instead of within current message

[JustSidus]

Issue for this PR

Closes #25254

Type of change

• Bug fix

What does this PR do?

The doom loop detection in processor.ts had two bugs:

1. Scope limited to current message only: MessageV2.parts(ctx.assistantMessage.id) only returns parts from the current assistant message. When a model repeats the same tool call across multiple messages (e.g. three separate turns each calling
   ead_file with the same path), the doom loop check silently passes because each individual message has fewer than 3 matching parts.

2. Slice before filter inverts the logic: parts.slice(-3).every(...) takes the last 3 parts regardless of type, then checks if all 3 match. If any text or reasoning part appears in the tail, every returns false and the check passes even when there are plenty of repeated tool calls in the message.

Fix: use MessageV2.filterCompactedEffect(ctx.sessionID) to search all messages in the session (same function already used by the prompt loop), filter matching tool parts first, then check if the count reaches DOOM_LOOP_THRESHOLD.

How did you verify your code works?

• �un typecheck passes in packages/opencode
• Reviewed the diff to confirm ilterCompactedEffect and ctx.sessionID are both available in the current codebase
• The previous PR fix(processor): fix doom loop detection scope and filter order #25255 identified the same root cause and proposed the same fix direction, but was closed by automated cleanup (not rejected for technical reasons)

Screenshots / recordings

Not applicable; logic-only change with no UI impact.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR