[Architecture] oclite: Streaming markdown strategy — incremental vs full rerender #75

Context

Research found two streaming markdown approaches in production:

Approach A: Incremental streaming (our current approach)

• File: packages/opencode/src/cli/lite/markdown.ts
• Parses markdown tokens as they stream in (bold, code spans, code blocks, headers, rules)
• Appends formatted ANSI output character-by-character
• Pro: Low latency, immediate output
• Con: Edge cases with split tokens across chunks (e.g., **bol then d**)

Approach B: Full re-render at 8fps (Aider's approach)

• Accumulate all text received so far
• Re-render entire markdown document from scratch every 125ms
• Use cursor repositioning to overwrite previous output
• Pro: Always correct rendering, no split-token edge cases
• Con: Flicker risk, higher CPU, needs cursor management

Decision Needed

Our incremental renderer works today. This issue tracks:

1. Monitoring for edge cases in the incremental approach
2. If edge cases pile up, switching to Aider's full-rerender approach
3. Consider hybrid: incremental for simple text, full-rerender for complex blocks

Current Implementation

• markdown.ts handles: bold (**), code spans (`), code blocks (```), headers (#), horizontal rules (---)
• Has flush() method that resets state and closes open ANSI sequences
• Adversarial-reviewed and fixed in commit 0a9608554

Acceptance Criteria

• Document any streaming markdown edge cases found during QA
• If 3+ edge cases found, implement full-rerender fallback
• Maintain current rendering quality