[FEATURE] Add chat:cycleEffort / chat:increaseEffort / chat:decreaseEffort actions for single-key effort switching

Preflight Checklist

• [x] I have searched existing requests — this has been filed three times before but all instances were auto-closed by the stale bot without maintainer review.
• [x] This is a single feature request.

Problem Statement

There is no global keybinding action to change reasoning effort level from the chat input. The existing modelPicker:increaseEffort / modelPicker:decreaseEffort actions only fire inside the ModelPicker context — i.e., only after the picker is already open via cmd+p. This forces a minimum 3-keystroke flow (cmd+p, →, enter) for what should be a single-key adjustment.

The /effort slash command works but requires typing and can't be bound to a hotkey.

Proposed Solution

Add three new actions in the Chat context that mirror the existing chat:cycleMode pattern (which already provides single-key mode cycling via shift+tab):

| Action | Behavior |
|---|---|
| chat:cycleEffort | Cycle through effort levels (low → medium → high → max → low) |
| chat:increaseEffort | Bump effort up one level (clamped at max) |
| chat:decreaseEffort | Bump effort down one level (clamped at low) |

Users could then bind whatever keys fit their terminal:

{
  "context": "Chat",
  "bindings": {
    "ctrl+shift+e": "chat:cycleEffort"
  }
}

This is a small surface-area addition — the underlying state mutation already exists (the model picker uses it, and /effort invokes it). Just expose it as Chat-context actions.

Alternative Solutions

• /effort slash command — works, but not bindable to a hotkey.
• cmd+p → arrow → enter — three keystrokes, breaks flow for power users adjusting mid-session.
• Terminal-side macro (e.g., Warp custom shortcut that types the keystroke sequence) — fragile; depends on terminal product and doesn't survive switching terminals.

Prior Art (please don't auto-close as duplicate of locked issues)

This has been requested multiple times. All prior issues were auto-closed by the stale bot without any maintainer response, and are now locked so further signal can't accumulate on them:

• #31519 — canonical request, auto-closed as not_planned due to inactivity, then locked. 4 👍, no maintainer reply.
• #41160 — duplicate-closed into #31519
• #49257 — duplicate-closed into #41160
• #32735 — duplicate-closed; specifically asks for Option+1/2/3 direct-set bindings
• Related: #38966 (single-key model cycling), #50323 (mode-aware effort)

Filing fresh because the locked issues can no longer collect 👍s or comments. Recurring asks from independent users across ~3 months is signal.

Priority

Medium — productivity papercut for power users who adjust effort frequently. Comparable to chat:cycleMode which already has the exact pattern.

Feature Category

Interactive mode (TUI) — keybindings

Use Case

Power users (especially those running Opus 4.7 at varying effort tiers) frequently dial effort up for hard architectural questions and back down for quick edits. The current 3-keystroke picker flow is slow enough that many users either (a) stay at one effort all session, or (b) use /effort which breaks the input flow. A single-key cycle would make effort switching as fast as mode switching is today via shift+tab.