fix(tui): answer a permission request at most once

[Yi-111-a]

Fixes #2565

Problem

The permission dialog is only torn down once the server's permission.replied event comes back. Until then the prompt keeps handling keys, and every one of them re-POSTed the same reply:

11:14:16 x2 -> 11:14:17 -> 11:14:20 -> ... -> 11:14:33   (Enter held down)

The report logged 32 replies for one requestID over ~8 minutes, and 141 in another session. The storm eventually wedged @opentui/core's setRawMode with EIO, after which Enter, Esc and Ctrl+C were all dead for the rest of the session — only kill -9 recovered it:

ERROR service=server-proxy e=setRawMode failed with errno: 5 exception
ERROR service=server-proxy error=EIO: i/o error, write exception

Cause

PermissionRequestPrompt calls sdk.client.permission.reply() directly from three places — the once/reject path, the always confirmation, and the reject-reason stage — with no guard. The server already drops a duplicate reply, so each extra POST was individually harmless; the storm was the whole problem.

Fix

Latch the reply per request:

let replied = false
const reply = (body: { reply: "once" | "always" | "reject"; message?: string }) => {
  if (replied) return
  replied = true
  void sdk.client.permission.reply({ ...body, requestID: props.request.id })
}

Per request rather than per prompt mount, because a confirmation answers and then drops back to the first stage:

onSelect={(option) => {
  setStore("stage", "permission")
  if (option === "cancel") return
  reply({ reply: "always" })
}}

A per-prompt latch is not sufficient here — the always stage sends its reply and returns to the permission stage, so a second Enter lands on a freshly mounted prompt that would answer again with once. Holding Enter through a confirmation therefore produced always then once for one request. The per-request latch covers all three call sites at once.

This is a behaviour fix only. Which reply wins is unchanged for every single-keystroke interaction, and no dialog, stage or keybinding changes.

Validation

Four regression tests in test/cli/tui/permission-bash-delete.test.tsx, on the existing mountPermission harness which records every /permission/*/reply POST:

test	covers
PermissionPrompt answers a held RETURN once	once, three Enters in one mount
PermissionPrompt answers a held ESCAPE once	reject, two Escapes
always confirmation answers a held RETURN once	always, two Enters on the confirmation stage
reject stage answers a held RETURN once	reject via RejectPrompt (harness gained an optional parentID so the request routes through the reject-reason stage)

Before / after, on the same tree:

before   29 pass   3 fail      (the three new held-Enter cases)
after    32 pass   0 fail

Also run:

• bun test test/cli/tui — 279 pass, 2 fail. Both failures are in session-list-visibility.test.ts, which scans source text for an absolute file:///… import and does not match this checkout's path. They fail identically on pristine main (275 pass, 2 fail), which is the same run plus these 4 tests.
• bun run typecheck (tsgo --noEmit) — clean.
• bunx oxlint on both changed files — 0 errors; the 2 warnings in permission.tsx (lines 56-57) are identical on pristine main.

permission-bash-delete.test.tsx is not prettier-clean on main either, so I left the surrounding formatting alone rather than reformatting the file inside this diff; the added tests follow the style already in it.

🤖 Prepared with AI assistance.