[data] Avoid stdin flood for non-TTY

[kkozoriz]

Description

Problem

In non-interactive environments (for example inside a pod, CI job, or any run without a TTY), AskYesNoWithTimeout could repeatedly print input error messages and create noisy output instead of gracefully falling back to a default decision.

Root cause

The confirmation loop kept retrying after read failures from stdin. In non-TTY scenarios this error is persistent, so the loop never recovered and continuously retried.
Additionally, the previous channel usage could lead to fragile behavior around timeout vs. input delivery.

Solution

• Detect non-interactive mode early and return a safe default without prompting.
• Use a buffered channel for one-shot answer delivery from the input goroutine.
• On stdin read error, stop retrying, choose a default answer, and exit the goroutine.
• Keep retries only for invalid user input (y/n validation).
• Add short inline comments to document the non-TTY and error-handling behavior.

Syscalls / TTY detection

AskYesNoWithTimeout uses golang.org/x/term.IsTerminal to detect whether the session is interactive.
This is the recommended cross-platform approach: it relies on OS-specific implementations under the hood (ioctl on Unix-like systems and GetConsoleMode on Windows via build tags).
No custom direct syscall logic was added in this change, so platform portability and builds remain safe.

Before fix

2026-02-27.12.27.10.mov

After fix