# Conflicts:
#	dor/package.json

The await-user path used window.confirm(), which a Tauri webview doesn't
support synchronously — it returned false instantly, so the command ended
immediately as "kill was not confirmed" and the dialog never opened.

Open the existing in-app kill dialog instead and block the control request
until the user accepts (matching letter) or rejects (Esc/any other key/
dismiss), wiring acceptKill/rejectKill to resolve the pending promise plus
a safety net that resolves false if the dialog is dismissed by another path.

A human-paced confirmation also outlasts both deadlines guarding the request,
so disable them for await-user kills: the dor client passes no timeout, and
the control server skips its safety-net timer (with a socket-close handler to
release the now-unbounded pending entry if the client disconnects).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

The await-user mode blocked the CLI call on a human answering an in-app
modal, but the interaction model doesn't hold up: a CLI invocation hanging
indefinitely on someone noticing a modal somewhere on screen — with no
mechanism to route attention to it — is the wrong primitive. The kill-confirm
dialog was also gated behind the Wall's command mode, so the confirm letter
never reached it from a terminal in passthrough mode anyway.

The remaining modes cover the real programmatic needs: --confirm-dangerously
(unconditional) and --confirm-if-read (guard on visible text). A proper
human-in-the-loop kill would need a non-blocking, attributed notification
channel; build that if a consumer actually needs it.

Reverts the await-user wiring across the CLI flag/parser, request types,
control client timeout handling, and the webview handler. Keeps the control
server's socket-close cleanup, which is a standalone correctness improvement.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

# Conflicts:
#	dor/test/snapshots/help/dor.md