[Fix] Task status line (→ ---) never updates with child tool

[randomm]

Problem

Task status line shows → --- but NEVER updates with actual child tool names (e.g., → bash git log). Works in TUI, broken in oclite. Attempted 15+ times to fix.

Root Cause (Definitive)

Two compounding issues:

1. chat() filters events to parent session only
session.ts:60: if (part.sessionID !== sessionID) return
Child session tool events never reach the streaming code path.

2. block.freeze() called when text arrives
index.ts:521: When prose text arrives, block.freeze() is called which:

• Stops animation
• Calls logUpdate.done() finalizing the output
• Subsequent setTaskChildTool() calls render() but the block is no longer live

The sequence:

1. Task starts → block.taskStart() → shows → ---
2. LLM outputs text → block.freeze() → block finalized
3. Child tool fires → Bus subscription calls setTaskChildTool() → render creates new output, doesn't update existing task line
4. User sees → --- forever

TUI Comparison

TUI uses SolidJS reactive store — task components re-render automatically when child data changes. No "freeze" concept.

Fix Options

Option A: Don't freeze block while tasks are running

if (chunk.type === "text" && chunk.content) {
  const hasRunningTasks = [...tasks.values()].some(t => t.status === "running")
  if (!hasRunningTasks) block.freeze()
  // ...
}

Option B: Separate task status rendering from live block

• Keep task status in a separate line that updates independently
• Don't use logUpdate for tasks

Option C: Re-architecture like TUI

• Global reactive event subscription
• Components update independently

Files

• src/cli/lite/index.ts — freeze logic, Bus subscription
• src/cli/lite/liveblock.ts — freeze(), setTaskChildTool()
• src/cli/lite/session.ts:60 — session filtering

Acceptance Criteria

• Task status line updates with actual child tool names
• Works even when LLM outputs text while task is running

[randomm]

Closed — oclite is being abandoned in favor of CodeNomad (standalone TUI). See #162 and epic #158.