v6: Add an operation picker to the Run button (#4419)

## Summary

- Brings back an explicit way to pick which operation runs. When the
document has more than one operation, the Run button grows a caret.
Clicking it opens a menu of every operation by name, and picking one
sets it as the active operation and runs it, the same behavior the old
execute button had.
- Cursor tracking is still the default. Moving the cursor into a
different operation re-activates it, even after a menu pick, so nothing
gets pinned. The menu marks the currently active operation.
- An operation that can't run under the current HTTP method (a mutation
while GET is selected) shows disabled in the menu, the same block reason
already shown on the button itself.
- The Run control now has visible `:focus-visible` and `:active` states.
Previously only the dead execute-button code had them.
- Removed the unused `ExecuteButton` component now that the TopBar owns
this menu directly. Keeping both around would leave two copies of the
same picker logic.

## Test plan

- [x] Write a document with two named operations. The Run button shows a
caret sized to match the Run half (same height, one seam). No operation
name sits beside the button.
- [x] Click the caret. A menu lists both operations, with the active one
marked. Pick the one the cursor is *not* in; that operation runs and
becomes active.
- [x] Move the cursor back into the other operation. It becomes active
again (cursor still wins; the pick wasn't sticky) — confirm via the mark
in the menu.
- [x] Add an operation that's invalid for the current method (e.g. a
mutation while on GET). Its menu item is disabled.
- [x] With a single operation (or none), no caret appears. The button is
a plain Run.
- [x] Keyboard: focus the caret, open with Enter/Space, move between
operations with arrow keys, press Escape. The menu closes and focus
returns to the Run button.
- [x] Looks modern: the menu matches the app's other dropdowns (elevated
surface, rounded corners, subtle shadow, highlight-on-hover); the caret
reads as one control with the green Run pill; both halves show a focus
ring on keyboard focus and a press state. Verify in light and dark.

Refs: #4288, #4219

Author: trevor-scheer

.changeset/operation-name-follows-cursor.md

@@ -3,6 +3,8 @@
 'graphiql': minor
 ---
 
-The active operation now follows the editor cursor. As you move the cursor between operations in a multi-operation document, `operationName` updates to the operation the cursor sits in, so the Run button, the operation dropdown, and operation-aware plugins all reflect where you are editing. Previously `operationName` only changed on run-at-cursor or via the operation dropdown.
+The active operation now follows the editor cursor. As you move the cursor between operations in a multi-operation document, `operationName` updates to the operation the cursor sits in, so the operation dropdown and operation-aware plugins all reflect where you are editing. Previously `operationName` only changed on run-at-cursor or via the operation dropdown.
 
 Two consequences if you embed GraphiQL: the `onEditOperationName` callback now fires when the cursor crosses into a different named operation, and a tab containing multiple operations shows the active operation name with a `+N` count of the others. Pinning an operation with the `operationName` prop still overrides cursor tracking.
+
+The Run button now offers an operation picker: in a document with multiple named operations, a dropdown on the Run button lets you choose which operation to run, and the menu marks which operation is currently active. The active operation still follows the editor cursor by default.

packages/graphiql-react/src/components/execute-button/execute-button.test.tsx

@@ -1,4 +1,3 @@
-export { ExecuteButton } from './execute-button';
 export { ToolbarButton } from './toolbar-button';
 export { ToolbarMenu } from './toolbar-menu';