[BUG] With /usage open, first Escape goes to the conversation (rejects pending tool call); second Escape closes the overlay

Version: 2.1.231 · Linux · terminal TUI

What happens
With an agent turn in flight (tool call pending permission or running), open /usage. Pressing Escape to dismiss the overlay does NOT close it — the first Escape is delivered to the conversation underneath, rejecting the pending tool call (the model receives the standard "user doesn't want to proceed" interrupt) while the /usage panel stays open. A second Escape then closes the overlay.

Expected
Key-handling priority should be the reverse: while an overlay is on top, Escape is consumed by the overlay (close it); only with no overlay open should Escape reach conversation-level actions like rejecting a tool call.

Impact
Not cosmetic: the rejection tells the model the user declined the action, so it stops mid-task and waits, and the user has to notice, explain, and re-drive the interrupted work. Hit twice in one day during normal use (glancing at /usage while a long investigation was in flight).

Repro

1. Ask Claude to run any Bash command that needs a permission prompt (or is long-running)
2. While it is pending, type /usage
3. Press Escape once → the tool call underneath is rejected; the panel is still open
4. Press Escape again → now the panel closes

Related (same family, different symptom): #79256 — /config Escape commits instead of cancelling. Both point at overlay key handling not owning Esc.