fix(interactive): flush stdout/stderr after streaming command output

[chaliy]

Summary

• Fix clear (and other commands producing output without trailing newlines) appearing delayed in interactive mode
• Root cause: print!()/eprint!() in the streaming callback are line-buffered on TTY — ANSI escape codes from clear (\x1b[2J\x1b[H, no newline) stayed buffered until rustyline's next prompt draw
• Add explicit stdout().flush() and stderr().flush() after each print!()/eprint!() in the streaming callback

What changed

crates/bashkit-cli/src/interactive.rs:

• Added use std::io::Write import
• Added std::io::stdout().flush() after print!() in the exec_streaming callback
• Added std::io::stderr().flush() after eprint!() in the exec_streaming callback
• Added test clear_command_streams_ansi_escape_codes verifying clear produces expected ANSI escape sequences via streaming

Why

Users reported that typing clear in interactive mode didn't clear the screen immediately — instead the screen cleared only when the next command was executed. This is because Rust's print!() macro uses line buffering when connected to a TTY, and the clear command's output contains no newline.

Test plan

• New test: clear_command_streams_ansi_escape_codes — verifies clear emits ESC[2J and ESC[H via exec_streaming
• All 86 bashkit-cli tests pass
• All 2363 bashkit lib tests pass
• cargo fmt --check clean
• cargo clippy -- -D warnings clean
• Smoke test: echo 'clear' | cargo run emits correct ANSI codes
• Audited codebase for similar unflushed print!/eprint! — only other occurrence is in main.rs one-shot mode where process::exit() follows immediately (OS flushes on exit)