What does this PR do?

In the TUI dangerous-command approval overlay (and the sibling clarify/confirm overlays that share the same blocked-input path), Ctrl+C was unconditionally treated as deny — so users couldn't select the displayed command and copy it for review before approving/denying. The first Ctrl+C rejected the request before the clipboard write ever ran.

This PR makes the keystroke selection-aware in the blocked-overlay branch of useInputHandlers:

• text selected → run the existing copySelection() (same path the unblocked branch uses via isCopyShortcut)
• nothing selected → existing cancelOverlayFromCtrlC() deny behaviour, unchanged

The pattern mirrors the precedent already in this file at line ~358 where Esc clears a selection before falling through to other overlay handling, and #16181's selection-vs-interrupt distinction.

Related Issue

Fixes #18375

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• ui-tui/src/app/useInputHandlers.ts — in the isBlocked branch for overlay.approval || overlay.clarify || overlay.confirm, when Ctrl+C is received, call copySelection() if terminal.hasSelection, otherwise the existing cancelOverlayFromCtrlC().

How to Test

1. hermes --tui
2. Trigger a dangerous-command security scan (any terminal command matching DANGEROUS_PATTERNS — e.g. ask the agent to rm -rf something).
3. When the approval overlay appears, select part of the displayed command with the mouse.
4. Press Ctrl+C — selection is copied to the clipboard, overlay stays open.
5. With no selection, press Ctrl+C — overlay dismisses with deny, same as before.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(tui): …)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix
• I've run pytest tests/ -q — pre-existing failures only, all in tests/tools/ (transcription, file_read_guards, terminal_tool_requirements) unrelated to this change. ui-tui vitest suite (548 tests) passes.
• I've added tests for my changes — the useInput callback in useInputHandlers.ts has no existing unit-test infra in this repo (sibling intercept paths are also untested at unit level); a hook-test scaffold would be a separate PR. Verified via tsc --noEmit and manual TUI repro.
• I've tested on my platform: macOS 15 (Darwin 23.2.0)

Documentation & Housekeeping

• I've updated relevant documentation — N/A (internal handler change, no user-facing docs reference this binding)
• I've updated cli-config.yaml.example — N/A
• I've updated CONTRIBUTING.md or AGENTS.md — N/A
• I've considered cross-platform impact — terminal.hasSelection is platform-agnostic; copySelection() already handles macOS/Linux/tmux/OSC 52
• I've updated tool descriptions/schemas — N/A