Define nonterminal input ownership for interactive elicitation

What problem would this solve?

Interactive CLI automation can supply input without a terminal, while extension forms also need answers. The supported ownership of queued input should be explicit so users can predict which prompts consume it.

What would a good outcome look like?

Define whether nonterminal --interactive stdin is a supported form-answer channel, independently of conversation input and instruction-file loading.

Possible approaches

Should extension forms accept generic nonterminal stdin, or require a terminal or dedicated explicit answer channel? State what --interactive opts into, how queued conversation input is preserved, and how a form behaves when no authorized input channel is available.

Verification should exercise the initial --text turn with queued stdin and an inert form, intentional automated answers if supported, terminal input, blank/default responses, EOF/partial EOF and cancellation. Keep ordinary headless behavior and both agent-loop paths consistent.

Additional context

This is an input-routing and compatibility decision; it does not prescribe a blanket ban on CLI automation or change existing EOF handling.

• I have verified this does not duplicate an existing feature request

Do not begin implementation until the issue reaches Ready on the Goose Issues board.