Thread header actions: show the action's icon, with its label as the tooltip #6520

The workflow

A plugin adds a button to the open thread's header with app.slots.experimental_threadAction({ placement: "header", ... }). The Git plugin's Commit is the first-party caller. Each registration must already provide an icon (static, for the picker) and every evaluated PluginThreadAction has a required icon, but the header ignores it and renders the label as text. As more plugins add header actions, the row of text buttons grows wide and competes with the thread title, while the workspace Open button right before it is already a compact icon with a tooltip.

What happens today

• One header action renders as an outline Button whose only child is action.label: ThreadDetailHeader.tsx#L257-L286.
• Several header actions render as a SplitButton whose primary half and dropdown items are label text only (same lines).
• The workspace Open button, rendered right before them, is icon-only with primaryTooltip: ThreadWorkspaceOpenButton.tsx#L55-L98.
• The contract documents the label-only button: app-contract.ts#L2151-L2165, and the audit entry lists this as open question 5: api_to_audit.md#L2844-L2849 ("Header buttons honor label and disabled only ... Decide whether header actions need ... an icon-only form").

Steps (bb 0.48.0, source at a0a0902, Linux 6.12):

1. Enable the Git plugin's Commit button and open a thread whose worktree has uncommitted changes.
2. Look at the header: Commit is a text button next to the icon-only Open button.

What you would expect

Header actions show their evaluated icon first, with the label as a hover/focus tooltip and the accessible name:

• One action: an icon-only outline button (same size and style as the workspace Open button), aria-label = label, tooltip = label. A disabled action still shows its tooltip.
• Several actions: the split button's primary half is the first action's icon with its label as tooltip; dropdown items show icon + label, like the menu rows.
• The compact/narrow-pane fold into the thread menu is unchanged (those rows already show icon + label).

This uses data every registration already supplies, so no SDK shape or wire change is needed; only the documented rendering of placement: "header" changes (contract comment, authoring docs, Plugin Guide bullet, audit entry).

Context and alternatives

• Alternative: an opt-in field (e.g. display: "icon" | "label"). Not proposed: it adds API surface for a choice bb can make consistently, and the audit asks to settle the header form before more plugins adopt it.
• Searched open and closed issues for "header action icon", "threadAction header", "header button icon tooltip": no match. Closest: Make page headers and sidebar footers bundled, forkable renderers #4833 (page headers as forkable renderers) and Tasks title bar: controls ride the plugin's second row, and nav panels cannot describe their route depth #1679 (Tasks title bar), both about nav panel headers, not thread action header buttons.
• Found while reviewing the experimental_threadAction API in a bb thread (thr_sgnr2jvsyu).

Checks

• I searched open and closed issues for the same request.
• If an agent wrote this, the body ends with > AGENT GENERATED.

AGENT GENERATED