Keybinding actions to set a specific permission mode directly (not just cycle)

Problem
Today the only mode control is chat:cycleMode (Shift+Tab), which steps through normal → acceptEdits → plan in sequence. There's no way to jump directly to a specific mode.

In practice my work splits cleanly into two opposite intents, and I want to express each with one deliberate keystroke:

• "This is serious — plan first, I'll review carefully before anything runs." → jump straight to plan mode.
• "This is well under control, I don't need to approve each step." → jump straight to auto-accept mode.

Cycling makes me think about where I currently am in the cycle and count taps, which is exactly the wrong cognitive load at the moment I'm trying to signal trust-level.

Cycle is unreliable mid-prompt
When a permission confirmation dialog is up, the cycle doesn't reliably switch modes the way it does at the normal prompt — so right when I've decided "actually, just let it run" or "stop, let's plan this," the one control I have behaves inconsistently. A discrete "set this mode" action would have unambiguous behavior regardless of what's currently on screen.

Stream Deck / macro-pad use case
This is especially important for hardware macro keys (Stream Deck, etc.), which send a single fixed keystroke. With only cycleMode, a physical button can't reliably reach a target mode — where it lands depends on the current mode, so the button does something different every time. Discrete "set plan" / "set auto" actions make a one-button-equals-one-mode physical setup actually work.

Request
Expose discrete, bindable actions for setting each permission mode directly, e.g.:

• chat:setModePlan
• chat:setModeAcceptEdits
• chat:setModeNormal
• (and chat:setModeBypassPermissions for completeness)

so users can bind them in ~/.claude/keybindings.json (e.g. meta+shift+p → plan, meta+shift+a → auto-accept) and map them to Stream Deck buttons. The existing chat:cycleMode stays as the default.

Workarounds today (all insufficient): Shift+Tab cycling; launching with --permission-mode plan|acceptEdits (only works at startup, not mid-session).

This has been previously posted, most similarly in #35251, but none of those "direct keybinding" issues are open.