Shutdown waits for an open prompt to be answered

• Status: Todo
• Kind: Bug
• Authors: jp
• Date: 2026-10-01
• Label: client=cli
• Label: package=jp_cli
• Label: package=jp_inquire
• Label: type=follow-up

A prompt runs on a blocking thread and reads the terminal until the user answers. Nothing outside the prompt can stop it: jp_inquire's backends (inline_select, inline_reply, text, select, password) take no cancellation.

When a turn ends while a prompt is open, the prompt keeps running. The main case is SIGTERM while a tool's approval prompt waits. lib.rs races the command against the shutdown token and drops the command future, but the blocking task keeps the prompt's writer and terminal reader. JP builds its runtime in build_runtime and drops it without shutdown_timeout or shutdown_background, and a dropped runtime waits for its blocking tasks. So JP does not exit until somebody answers the abandoned prompt.

Question and result-review prompts have run this way since before PR #1175. That PR moved approval prompts onto a blocking thread too. Before, the approval prompt blocked the thread rt.block_on polls, so shutdown did not even see SIGTERM until the prompt was answered.

The damage is contained and visible: the prompt is on screen, and one key or Ctrl-C ends it. A closed terminal fails the read, and the prompt exits on its own.

Proposal

1. Give the prompt backends a stop handle that wakes their input wait and returns InquireError::OperationCanceled, for example by polling crossterm events with a timeout and checking a token.
2. Pass the turn's cancellation, or the shutdown token, to every prompt ToolPrompter opens, so ToolCoordinator::abandon and shutdown both close the prompt they leave behind.
3. Regression test: hold an approval prompt open, request shutdown, and check that the prompt's worker exits without an answer.

Raised in review of PR #1175 (comment 4155441004).