2.5.21 Show ready/blocked readiness in the `/issues` quick-view modal

Estimate: 8m · Depends on: 2.5.19, 2.5.20

Render the ready / blocked signal inside the /issues quick-view (peek) modal per 2.5.20's design, so a user can tell while scanning the list whether a peeked item is Ready to start or Blocked (and on what) without opening the full page. This is a purely presentational addition to the 2.5.19 modal — no new read, no new mutation, no new visual primitive.

The data is already in hand. The peek renders from the shipped getIssueDetail(projectId, key, ctx) (2.4), whose IssueDetailDto ALREADY carries readiness: ReadinessVerdictDto ({ ready, openBlockers }) — the same verdict the detail page's relationships panel feeds to ReadinessBadge. So 2.5.21 drops the shipped components/ui/ReadinessBadge (2.4.5) into the IssueQuickView modal, fed from detail.readiness, at the placement 2.5.20 specifies. Map openBlockers to the badge's { identifier, href } exactly as the detail page does (reuse that mapping — do NOT re-derive readiness; the service owns the per-project terminal classification, finding #21).

Match the design's rules: show NO banner when the item has no blockers (mirror the detail-page rule — 2.5.20 confirms it); the open blockers are named as links to /issues/[key], with the swap-peek-vs-navigate behaviour 2.5.20 decides; readiness state is conveyed by text + icon, never colour alone (the badge already does this); colours via --el-*.

Scope guard. Only the readiness signal moves into the peek — the full relationships / links panel STAYS detail-only (no link create/remove, no Blocks/Relates-to/Duplicates groups in the peek). v1 = render the existing badge from the already-returned verdict (no complexity for nothing).

Acceptance criteria

• The quick-view modal renders the shipped ReadinessBadge from detail.readiness per quick-view.mock.html (2.5.20): blocked names the open blockers as /issues/[key] links, ready shows "Ready to start", an item with no blockers shows no banner.
• Reuses getIssueDetail's existing readiness field + the ReadinessBadge primitive — NO new read, NO new component, NO re-derivation of readiness; the relationships/links panel stays detail-only.
• The named-blocker links behave as 2.5.20 specifies (swap ?peek= or navigate to full page); the badge never breaks the modal's focus-trap / Esc / return-focus or the non-nested row trigger; colours via --el-*, state by text + icon not colour alone (finding #35).
• Component test: a blocked item's peek renders the blocked badge with the open-blocker links; a ready item renders "Ready to start"; an item with no blockers renders no banner. tsc / eslint / prettier clean; next build compiles.

Context refs

• design/work-items/quick-view.mock.html + design-notes.md (2.5.20) — the layout authority
• The 2.5.19 IssueQuickView modal (app/(authed)/issues/_components/*) — the surface to extend (where the badge mounts)
• components/ui/ReadinessBadge.tsx (2.4.5) + app/(authed)/issues/[key]/page.tsx (how the detail page feeds detail.readiness → ReadinessBadge, incl. the openBlockers → {identifier, href} mapping to reuse)
• lib/dto/workItems.ts ReadinessVerdictDto / IssueDetailDto.readiness; lib/services/workItemsService.ts getReadiness (the read already wired into getIssueDetail); motir-core/CLAUDE.md — --el-* tokens