[BUG] `openfang init` panics in non-TTY environments (ratatui terminal init failure)

[houko]

Description

openfang init panics when run in a non-TTY environment (e.g., CI pipelines, IDE integrated terminals, or agent automation contexts). The panic originates from ratatui's terminal initialization.

Environment

• OS: macOS (Darwin arm64, Apple Silicon)
• OpenFang version: 0.3.26
• Installation method: curl -fsSL https://openfang.sh/install | sh

Steps to Reproduce

1. Install OpenFang
2. Run openfang init in a non-TTY context (e.g., piped stdin, or a subprocess without a real terminal):

echo "" | openfang init

Error Output

thread 'main' (4583951) panicked at /Users/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ratatui-0.29.0/src/terminal/init.rs:52:16:
failed to initialize terminal: Os { code: 6, kind: Uncategorized, message: "Device not configured" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Expected Behavior

openfang init should either:

1. Detect the non-TTY environment and fall back to non-interactive mode automatically, or
2. Print a helpful error message suggesting the user run openfang setup --quick instead

Actual Behavior

Hard panic with a Rust stack trace. Exit code 101.

Workaround

Use openfang setup --quick which works correctly in non-TTY environments.

Suggestion

A simple isatty(stdin) / isatty(stdout) check before initializing ratatui would prevent the panic and improve the experience for headless/automated deployments.

[jaberjaber23]

Fixed. Added TTY guard in init_wizard.rs that checks both stdin and stdout with std::io::IsTerminal before calling ratatui::init(). Also updated the main.rs fallback to check stdin in addition to stdout. Non-TTY environments now fall back to quick init mode.