2.4.15 Design — Sprint field on the detail core-fields rail + 'Add to active sprint' in the ⋯ actions menu

Design prerequisite for code subtask 2.4.14 (MOTIR-1003) — Sprint inline-edit field on the work-item detail + 'Add to active sprint' ⋯-menu action. The design gate fires: both additions land on ALREADY-DESIGNED surfaces (detail.pen core-fields rail + delete-confirm.mock.html ⋯ menu) that do NOT currently include them, so they are undesigned elements — NOT mere grammar reuse. This mirrors how custom fields on the same rail (5.3.5 → 5.3.7) required their own design asset (custom-fields.mock.html) even though they reused FieldCard + Combobox verbatim.

Produce the THREE-file design asset set under design/work-items/ (a *.mock.html built from the real design system + a same-basename .png export + an update to design-notes.md), covering BOTH elements. DRAW THE ACCESS PATH for each — show the entry affordance in context (the field's place in the rail; the menu item open in the ⋯ menu), not just the destination.

What must be designed

1. Sprint FieldCard on the detail core-fields rail (CoreFieldsPanel)

The shipped rail built-ins are Status · Assignee · Reporter · Priority · Due · Estimate · Parent (detail.pen); there is NO Sprint field. Decide:

• Placement among the built-ins (Sprint is an agile-planning field — near Parent? after Estimate, before the custom-fields block? its own position). Built-ins never reorder, so fix where Sprint inserts.
• Value-line rendering — sprint NAME plain, or a Pill? How the no-sprint / Backlog state reads (the rail's muted-italic None grammar, or an explicit 'Backlog'?). Whether the sprint's lifecycle state (planned/active/complete) is indicated.
• The inline picker — the shipped Combobox (the AssigneePicker-shaped composition): the sentinel row. The filter's sprint-select puts a Backlog sentinel FIRST; the AssigneePicker puts None/Unset first. Pick one and state it. Searchable threshold (the ≥8-options Combobox rule).

2. 'Add to active sprint' in the ⋯ WorkItemActionsMenu

The shipped menu (Story 2.8/2.9, delete-confirm.mock.html) has a FIXED item set — Edit details · Copy link · — · Archive · Delete… — with no Sprint action, and is IDENTICAL across detail header / list rows / board cards. Decide:

• Placement / order / icon / label of the new row, and which group it joins (a new section above the Archive/Delete separator?).
• ⚠️ Grammar conflict to resolve: the card asks to 'grey it out / disable + tooltip when there is no active sprint', but the menu's established law is permission-gated rows are HIDDEN, never shown-disabled (WorkItemActionsMenu source comment). A no-active-sprint state is a STATE gate, not a permission gate — decide whether disabled+tooltip is the right deviation here (and document why) or whether to hide it. Check the mirror (Jira/Linear 'Add to sprint' behaviour) at rung 1.
• Whether this row appears on the list-row/board-card instances too (the menu is shared) or only on the detail header.

Acceptance criteria

• design/work-items/<basename>.mock.html + <basename>.png + a design-notes.md section, covering both elements with every state (field populated / Backlog / editing; menu item enabled / disabled-or-hidden no-active-sprint).
• The access path is DRAWN: Sprint field shown in its rail position; the menu item shown open in the ⋯ menu in context.
• The disabled-vs-hidden grammar decision is stated with its rationale (rung-1 mirror check cited).
• The sentinel + value-line + placement decisions are explicit, so 2.4.14 builds with zero improvisation.

Context refs

• design/work-items/detail.pen (rail) · design/work-items/delete-confirm.mock.html (the ⋯ menu) · design/work-items/custom-fields.mock.html (the new-rail-field precedent) · design/work-items/design-notes.md
• app/(authed)/issues/[key]/_components/CoreFieldsPanel.tsx + FieldCard.tsx (the rail) · components/issues/actions/WorkItemActionsMenu.tsx (the menu, + its hide-never-disable comment) · components/issues/AssigneePicker.tsx + components/ui/Combobox.tsx
• Blocks 2.4.14 (MOTIR-1003).