fix(prompts): make destructive confirms one keystrokeHEADmain

I had to kill an Emacs session today over a prompt I could not answer. A
second agent session held the selected window while "Overwrite hiroshi.m3u?
(yes or no)" waited in another frame, so my keystrokes went to a terminal
and the minibuffer stayed empty. Losing unsaved buffers is a far worse
outcome than a mis-keyed confirm.

So cj/confirm-strong becomes cj/confirm-destructive, and instead of binding
use-short-answers to nil for a typed "yes" it reads a single y or n.

Two things I kept:

- No default. Only y and n answer, so a stray RET or space re-prompts
  rather than confirming a shutdown.
- Pending input is discarded before the read. Without that the change would
  have been a bad trade: read-char-choice reads the input queue, so a key
  typed before the prompt painted would confirm instantly, where the old
  typed-"yes" absorbed it harmlessly.

Worth being honest about what this does not fix. One keystroke does not
make a prompt reachable when focus is elsewhere, and C-g is still the
escape. It lowers the cost of the situation rather than preventing it.

Six call sites: shutdown and reboot, shred, playlist overwrite and delete,
and the two file overwrites.

0 files changed, 0 insertions, 0 deletions