perf: optimize repetition detection for high-frequency streaming

[terisuke]

背景

GLM-5.1 thinking corruption fix（Issue #52）でrepetition detectionを実装。

問題

現在のdetectRepetition()はO(n*m)で���全てのtext-deltaイベントで呼ばれる。
高速ストリーミング時に性能影響の可能性がある。

対策案

• N文字蓄積ごとにチェック（例：500文字ごと）
• Rolling hashアルゴリズムの採用
• キャッシュベースの最適化

現状

実測では1ms以下で完了するため、現時点ではブロッカーではない。
高速モデル（GPT-5.x等）での負荷テスト後に再評価。

関連

• Issue [Bug] GLM-5.1 thinking output corruption — repetition loop + tool call leak #52 (GLM-5.1 thinking corruption)
• Upstream Issue: [BUG] GLM-5 model pollutes context window with broken thinking output anomalyco/opencode#16903

[terisuke]

進捗更新: detectRepetition は repetition.ts に抽出済み (PR #70)。ただしアルゴリズム自体は同一のネステッドスキャンのまま (repetition.ts:8)、processor.ts:162,373 で毎 delta 呼び出し。性能最適化は未着手。

[terisuke]

Note: upstream/dev has the repetition detection removal in preparation on feature branches (not yet merged to dev). When upstream merges, repetition.ts will be deleted. No optimization needed.

[terisuke]

Closing as won't-fix for now. Per the issue body itself:

実測では1ms以下で完了するため、現時点ではブロッカーではない。
高速モデル（GPT-5.x等）での負荷テスト後に再評価。

The repetition detection runs in sub-millisecond time. No measurable performance impact observed with current models (GPT-5.4, GLM-5.1, Claude Sonnet 4.5). If future high-speed models expose latency, reopen with profiling data.