CLI: no non-interactive path through gt init / gt configure, and gt init exits 0 in CI having written nothing

[JoshKappler]

gt init takes only --src and --config, and gt configure takes no options; both are prompt wizards (verified on 2.14.63 and 2.14.64). Two consequences:

• There is no flag-driven setup for CI or agent-driven flows. The working headless path is hand-writing gt.config.json and setting GT_API_KEY / GT_PROJECT_ID, which the docs now cover (content#393), but a supported --yes style init would close the gap properly.
• Worse, npx gt init with stdin closed exits 0 having created no files, so a CI script checking exit codes believes setup succeeded. A non-TTY detection with a clear error and nonzero exit would make the failure honest even if the flag never ships.

Related wart seen while testing: gt init prints "No package.json or Python project file found" in a directory containing a valid package.json from npm init -y (gt 2.14.63).

If wizard-only setup is deliberate, the non-TTY exit-code fix alone would still be worth it.

[ShuqingZou]

Still reproduces on gt@2.16.3 (Node v22.23.2). In a fresh dir after npm init -y:

$ npx gt@latest init < /dev/null; echo "exit=$?"
┌  Running setup wizard...
◆  Would you like to use the recommended General Translation defaults?
exit=0

No gt.config.json is written. Worth noting the wizard renders its first prompt before giving up, so nothing detects the non-interactive stdin up front. (The missing-project warning shows here too, I see that's tracked in #2030.)

I'd like to take the narrow fix you described: detect non-TTY stdin before the wizard starts, error with a pointer to the documented headless path, and exit nonzero. Interactive runs unchanged, --yes out of scope.

One question — should that check live per-command in init / configure, or in the shared prompt layer so other interactive commands get it too?