[oclite] 20-second input delay after TUI renders

[randomm]

Description

After the TUI renders, there's a ~20 second delay before user input becomes responsive. The Ink useInput hook doesn't fire during this period, completely blocking user interaction despite the UI appearing ready.

Evidence

Debug logs show a consistent 20.6 second gap between component mount and input readiness:

11:03:20.735Z InputLine MOUNT: InputLine mounted focus:true, disabled:false
11:03:41.352Z InputLine INPUT: useInput callback fired
→ 20.6 seconds where input is completely blocked

• Component mounts with correct state (focus:true, disabled:false)
• Ink rendering completes successfully
• stdin appears ready but doesn't respond
• After ~20s, input suddenly becomes responsive

Hypotheses

1. Ink stdin setup delay: Ink's stdin listener registration may be deferred or blocked
2. Event loop blocking: Long-running synchronous operation blocking Node.js event loop
3. SDK subscription interference: SDK stream subscription may be interfering with stdin
4. Async initialization race: Critical async setup completing after render but before input readiness

Investigation Steps

1. Profile event loop blocking
2. Trace Ink stdin setup - check if process.stdin.setRawMode() is delayed
3. Measure SDK initialization timing
4. Isolate component mount vs input readiness
5. Test minimal reproduction outside full TUI

Acceptance Criteria

• Root cause identified and documented
• Input becomes responsive within 1 second of TUI render
• No regression in plugin initialization
• Debug logs added to track input readiness lifecycle

Related

• Partially addressed by plugin delay fix in [Fix] oclite TUI non-functional - missing text streaming handler & silent failures #142

[randomm]

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