Doom-loop detection misses periodic tool-call cycles

Description

The doom_loop guard detects three adjacent identical tool calls, but misses alternating calls such as A, B, A, B, A, B. Repeating the same multi-call block never satisfies the current last-three-parts comparison.

I reproduced this with a deterministic normalized stream driving the real SessionProcessor, without changing production code. The period-2 regression fails because processing returns continue without asking permission. A period-1 control (A, A, A, with distinct call IDs) passes.

Plugins

None in the reproduction fixture.

OpenCode version

Upstream dev at 57ef3828431790c53f8f333c7ffbfe88770a1812.

Steps to reproduce

1. Configure doom_loop: "ask" and create a fresh assistant processor.

2. Supply a normalized stream with step-start, followed by these calls in order. Give every call a unique ID and follow each with a successful tool-result:

   lookup({query: "a"})  call-a1
   search({query: "b"})  call-b1
   lookup({query: "a"})  call-a2
   search({query: "b"})  call-b2
   lookup({query: "a"})  call-a3
   search({query: "b"})  call-b3
   

3. End with step-finish(tool-calls) and finish(tool-calls).

4. Observe six completed tool parts, no permission.asked event, and processor result continue.

Expected: three complete repetitions of this two-call block should reach the existing doom_loop permission gate, just as three repetitions of a single call do.

This is distinct from #46272's consecutive-identical-call stop threshold and #32089's cross-message history scan. The sequence above occurs entirely within one active processor. It does not require changing permission actions or adding an unconditional stop.

Operating System

Linux. Reproduced in the processor Effect test suite, without an external provider.