[Bug]: Ink TUI renders gray/dim text as invisible when TERM/COLORTERM are unset (code blocks, diagnostics panels appear blacked out)

Description

When OpenWiki is launched from a shell where TERM and COLORTERM are both empty/unset, gray/dim-styled text in the Ink TUI renders as effectively invisible — same color as the background. This affects any panel that leans on dim/gray styling for secondary content, notably CredentialDiagnosticsPanel and ErrorDiagnosticsPanel (src/cli.tsx:673-720), and code-block/tool-output rendering in the interactive chat.

This was diagnosed empirically in a live session (not guesswork): echoing raw ANSI codes (\033[90m, \033[37m) directly to the same terminal showed the codes rendering correctly once TERM=xterm-256color and COLORTERM=truecolor were exported, and rendering blank/invisible with both variables empty. Re-launching with:

TERM=xterm-256color COLORTERM=truecolor openwiki

restored visibility of the previously-blacked-out text.

Note: TERM/COLORTERM are never referenced anywhere in OpenWiki's own source (confirmed via full-tree grep) — the dependency is transitive, through whatever color-support detection Ink's rendering stack uses. So OpenWiki has no direct code path that's "wrong," but it also has no fallback/guard for the case where these variables are empty, which silently produces unreadable output with no warning to the user.

Separately, in the same environment, these diagnostic panels also showed visually overlapping/ghosted text between consecutive re-renders (an earlier, wider line's characters bleeding through behind a shorter line drawn after it). I haven't isolated a root cause for that part with the same confidence as the color issue — flagging it for awareness in case it's a related Ink redraw/erase-line artifact under the same terminal conditions, rather than asserting a fix.

Steps to Reproduce

1. In a shell, unset TERM COLORTERM (or start from an environment where they're already empty — this reproduced on a Termux/Android shell).
2. Run openwiki interactively and trigger any panel with dim/gray text — e.g. an error that shows ErrorDiagnosticsPanel/CredentialDiagnosticsPanel with OPENWIKI_DEBUG=1 set, or any assistant code block.
3. Compare against running TERM=xterm-256color COLORTERM=truecolor openwiki in the same shell.

Expected Behavior

Text should be legible regardless of whether the parent shell happened to export TERM/COLORTERM, or OpenWiki should detect the no-color-support case and fall back to a safe rendering mode (e.g., force a minimum contrast, or disable dim styling entirely) rather than silently emitting content that becomes unreadable.

Actual Behavior

Any dim/gray-styled content — including panels meant to carry important diagnostic information — is fully invisible until the user happens to relaunch with explicit TERM/COLORTERM values.

Suggested Fix

• Don't rely solely on inherited TERM/COLORTERM for color-level detection. Consider forcing a known-good color level (e.g., chalk.level = 3 / equivalent Ink color-support override) at startup instead of trusting ambient env vars.
• At minimum, detect the no-color-support case and either warn the user explicitly or drop to plain (non-dim) text so nothing becomes unreadable.

Environment

• OS: Android / Termux
• OpenWiki: local dev checkout, main-adjacent branch
• Node.js: (Termux-provided)