InlineSamplingRequest: replace responseText scalar with draftResult: CreateMessageResult

[cliffhall]

Background

Documented as a Phase 5 audit partial in specification/v2_ux_interfaces.md (PR #1236). InlineSamplingRequest currently exposes a flat responseText: string prop. The spec target is draftResult?: CreateMessageResult — the same wrapper that SamplingRequestPanel already accepts — so the inline card and the full panel can share the editor's draft state when the user expands an inline request into the panel.

The current scalar prop predates the panel-level draft-state work and was never reconciled.

Acceptance criteria

• InlineSamplingRequest's prop interface drops responseText: string and adds draftResult?: CreateMessageResult (imported from @modelcontextprotocol/sdk/types.js).
• When draftResult is undefined, the card renders the existing "no draft yet" affordance (auto-respond / edit-and-send / reject / view-details buttons unchanged).
• When draftResult is defined, the card displays a 1-2 line preview of draftResult.content (text content only — image/audio fall back to a [Image content] / [Audio content] label per the existing ContentViewer convention).
• No callback signature changes; existing handlers (onAutoRespond, onEditAndSend, onReject, onViewDetails) keep current shapes.
• InlineSamplingRequest.stories.tsx covers: (a) no draft (current default), (b) text draft, (c) draft with non-text content block.
• PendingClientRequests and any other consumer threading responseText through is updated (likely none — verify with grep).

Test plan

• npm run format && npm run lint && npm run build clean.
• All three new stories render in Storybook and the action logger fires expected events.
• Visual diff vs. before: the no-draft case is identical; the with-draft cases show new preview text under the existing layout.
• No leftover references to responseText in the web client (git grep responseText should only show unrelated matches).

Out of scope

• Inline editing of the draft inside the compact card (that lives in SamplingRequestPanel).
• Adding a draftResult editor that mutates state — the inline card is read-only.
• Changing how SamplingRequestPanel consumes draftResult (already correct per audit).

Open design question

The audit deferred this with the note "the inline card's draft-editing UX is co-evolving with SamplingRequestPanel". Before implementing, confirm: should the inline preview reflect the live draft from the panel (shared state, two views), or remain a static "last received draft" snapshot? Default proposal: shared — implementer should pull from the same pending-request store the panel reads.

Related

• Spec entry: specification/v2_ux_interfaces.md § InlineSamplingRequest
• Companion: specification/v2_ux_interfaces.md § SamplingRequestPanel
• Audit: PR Phase 5 audit: annotate spec, close HistoryControls partial #1236