fix(session): avoid repeated full-history summary loads during multi-step loops

[sjawhar]

Issue for this PR

Closes #21761

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Fixes a high-impact session performance bug where tool-using sessions repeatedly reloaded the full session history during a single user prompt.

Root cause:

• SessionProcessor called SessionSummary.summarize(...) inside the finish-step handler
• finish-step runs once per assistant model turn, not once per overall user prompt
• SessionSummary.summarize(...) loads the full session history with sessions.messages({ sessionID })
• Tool-using agents can take many model turns in one prompt, so this caused repeated full-history hydrations and multi-GB RSS growth

Fix:

• remove the processor-side SessionSummary.summarize(...) call from session/processor.ts
• keep summary responsibility at the prompt-loop level instead of per-step
• add a cheap guard in session/summary.ts to return early when the target user message already has summary.diffs

How did you verify your code works?

• cd packages/opencode && bun test test/session/prompt-effect.test.ts --test-name-pattern 'loop continues when finish is tool-calls|loop continues when finish is stop but assistant has tool parts|loop summarizes once across a multi-step tool run'
  • 3 pass, 0 fail
• cd packages/opencode && bun test test/session/processor-effect.test.ts
  • 12 pass, 0 fail
• cd packages/opencode && bun typecheck
  • pass

Regression evidence

New regression test went red → green:

• before fix: summaries = 3
• after fix: summaries = 1

That reproduces the bug directly in a two-step tool loop and proves the processor-side summary call was the repeated trigger.

Live diagnostic evidence

Labeled diagnostic binary showed the bad sequence in a real frozen session:

• prompt loop entry: 4
• summary start: 4
• summary loaded messages: 4
• prompt loop summary trigger: 1
• prune start: 0
• session messages full: 10
• message hydrate: 45

This proved:

• prompt loop re-entry was happening during multi-step tool execution
• repeated full-history loads were coming from summary, not prune
• the processor-side summary caller explained the extra repeated loads beyond the one prompt-loop trigger

Notes

• This bug likely contributed to both standalone TUI freezes and shared serve memory drift on long-running tool sessions
• Windows e2e remains flaky on dev; unrelated to this change

Checklist

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