(triggers): typing into a session is blind to CLI dialogs, and a blocked session tells its driver nothing

[jbr-sekoia]

Driving sessions from outside, through the trigger watcher or sendInput, exposed two gaps:

• After a task, the CLI opened a dialog ("Teach auto mode about your environment?"). The next two prompts sent to the session landed in that dialog, not in the composer, and were lost; the session sat idle for about an hour. The composer-state check the trigger watcher uses did not treat the dialog as "not a composer".
• A session blocked on a permission prompt ("Do you want to proceed?") sat for an hour, twice. The sidebar showed "waiting" correctly, but nothing reaches whoever is driving the session: a trigger's result only reports submission.

Expected:

• a trigger (and any typed input) is held back when the CLI shows a dialog rather than its composer, and the result says so;
• the waiting state can be observed by a driver, e.g. a trigger chain step that waits for idle reports "waiting for a permission prompt" instead of timing out.

Related: #360 (a chain step waiting for idle that never comes).

[devsuitup]

Scope note for "any typed input": keystrokes, pastes, drops and the context-menu paste all reach the PTY through the same fire-and-forget terminal-input IPC. Nothing tells a person from a program, and a driver acting through the renderer uses the same call. Holding that input while a dialog is open would also block the keystrokes that answer the dialog. Typed input therefore stays unheld by design, as recorded in .ai/contexts/trigger-watcher.md. Programmatic drivers go through triggers, which hold on a dialog (#414 chains, #424 single triggers).