feat(ai-vterm): gate the F9 launcher to GUI frames

AI-vterm launches a graphical vterm side window, so F9 / C-F9 / M-F9 now decline with a message in a terminal frame instead of opening a vterm. The guard checks the current frame at command time rather than at load. That matters under the daemon, which serves GUI and terminal frames both with display-graphic-p nil at load, so a load-time gate would have disabled the launcher in its GUI frames too.

Routed the three window-behavior tests through a GUI-frame stub, since a batch run is itself a terminal frame.

1 files changed, 8 insertions, 0 deletions

diff --git a/todo.org b/todo.org
index 6fa2161e..0b9f8c2e 100644
--- a/todo.org
+++ b/todo.org
@@ -153,6 +153,14 @@ What we're verifying: emoji glyphs + fonts apply in a GUI frame even when the fi
 - in the GUI frame, open a buffer with an emoji and check it renders, and M-S-f / fonts look right
 Expected: emoji renders and fonts are applied in the GUI frame.
 
+*** AI-vterm declines in a terminal frame, still launches in a GUI frame
+What we're verifying: the per-frame guard makes the F9 family decline — message only, no vterm — in a terminal frame, while a GUI frame still launches the agent.
+- emacsclient -t   (TTY frame, off the running daemon)
+- in the TTY frame, press F9 (also try C-F9 and M-F9)
+- emacsclient -c   (then a GUI frame)
+- in the GUI frame, press F9 and pick a project
+Expected: in the TTY frame the echo area shows "AI-vterm is GUI-only; not available in a terminal frame" and no vterm opens; in the GUI frame the project picker opens and the agent launches as before.
+
 ** DOING [#B] Consolidate to EAT as the single terminal :terminal:eval:
 :PROPERTIES:
 :LAST_REVIEWED: 2026-05-28