On Linux, the CLI input prompt has a cursor positioning offset that causes the first character of typed input to appear separated from the rest by a space. For example, typing "what" displays as "w hat".
This is the same class of issue as #3364 (Windows cursor shift), which was fixed in PR #4464 by stripping ANSI escape sequences on Windows. The Linux prompt still uses styled ANSI sequences and the 🪿 emoji, both of which can cause rustyline to miscalculate display width.

To Reproduce

1. Run goose (interactive mode) on Linux
2. Type any message at the prompt
3. Observe the first character is visually separated from the rest of the input

Expected behavior
Text should appear contiguous as typed, with no spurious space after the first character. Currently it looks like:
🪿w hat" instead of "what"

Environment

• OS & Arch: Linux 6.14.0-37-generic (x86_64)
• Interface: CLI (VS Code integrated terminal / Cursor IDE)
• Version: 1.25.0
• Provider & Model: lemonade / Qwen3-Coder-30B-A3B-Instruct-GGUF

Additional context

• The Windows variant of this bug (Cursor shifted to the right using native windows CLI #3364) was fixed in PR fix: Windows prompt cursor positioning issue with ANSI escape sequences #4464 by conditionally stripping ANSI escape sequences from the rustyline prompt via cfg!(target_os = "windows").
• The root cause is in rustyline's width calculation for ANSI escape sequences and/or the 🪿 (U+1FABF) emoji. Upstream tracking: Colored prompts behave incorrectly on Windows kkawakam/rustyline#562, pending fix: On windows, check that prompt is not styled kkawakam/rustyline#890.
• A possible fix would be to extend the ANSI-stripping workaround from PR fix: Windows prompt cursor positioning issue with ANSI escape sequences #4464 to Linux, or to wrap the styled portions of the prompt in rustyline's special markers (\x01/\x02) so it can correctly exclude them from width calculation.