Summary

Fix readline/TTY errors to propagate as quick exits instead of being silently swallowed or displayed as inline errors, ensuring the process terminates cleanly when the terminal is unavailable.

Context

When Forge runs in a non-TTY environment (e.g., piped input, CI, or other headless contexts), the readline prompt fails with an I/O error. Previously, these errors were treated identically to recoverable runtime errors — they were displayed inline and the loop continued, leading to confusing behavior or infinite error loops. This fix ensures that readline failures cause a clean, immediate exit with the error propagated to the caller.

Changes

• Introduced a dedicated ReadLineError wrapper type (using thiserror) to distinguish readline/TTY failures from other runtime errors
• Updated ForgeEditor::prompt to wrap I/O errors in ReadLineError so they can be identified downstream
• Updated the UI error-handling loop to detect ReadLineError and return early (quick exit) instead of displaying the error inline
• Added all errors to tracker and tracing before the readline type check so nothing is lost
• Added a comment explaining the TTY failure behavior on the first prompt call

Key Implementation Details

The error discrimination uses error.downcast::<ReadLineError>() after logging/tracking the error. If the downcast succeeds, the error is re-returned immediately via Err(error)?, causing the entire UI task to exit. If it fails (a normal recoverable error), the existing inline display path is used. This ensures zero behavioral change for non-readline errors.

Testing

# Run crate-specific tests
cargo insta test --accept -p forge_main

# Simulate a non-TTY environment to trigger readline error path
echo "hello" | cargo run -- --help

# Verify clean exit code on TTY failure
echo $?

Links

• PR: fix(ui): propagate readline/TTY errors as quick exit #2570