2.4.5 Relationships panel + ready/blocked badge (first `isReady` caller)

Estimate: 12m · Depends on: 2.4.1, 2.4.7

The dependency surface — and the first production wiring of 2.2.6's isReady (finding #21's payoff; until now it has only a _test caller). A relationships panel lists the item's links from the work_item_link table (1.4.3): blocked by (its blockers), blocks, and the other Jira-style kinds shipped (relates_to / duplicates / clones) grouped by kind, each linked item shown with icon + identifier + title + status pill. A prominent ready / blocked badge reflects workflowsService.isReady: "Blocked" when any blocker is non-terminal (each blocker judged against ITS OWN project's terminal set — 2.2.6), "Ready" when all blockers are terminal (done/cancelled). The badge names the open blocker(s) so the reason is legible.

Scope discipline. This panel READS links — creating/removing links is a later surface, planned as 2.4.8 (design) + 2.4.9 (code) below (NOT Epic 5 — Jira puts "Link issue" on the detail view, so it's PM-core/Epic 2). So here the panel is read-only with a documented "manage dependencies" extension slot. The blocked/ready badge is the same primitive Epic 3 boards + Epic 6 reports will reuse, so it's a small presentational component (ReadinessBadge) fed by the service verdict, not bespoke page markup.

Acceptance criteria

• Relationships panel groups links by kind (blocked-by / blocks / relates-to / duplicates / clones); each linked item shows icon + identifier + title + status and links to its detail page; no links → the panel shows a muted empty state, not blank.
• The readiness badge reads isReady: "Blocked" (naming the open blocker[s]) when a blocker is non-terminal, "Ready" when all are terminal — terminal judged per the blocker's own project (2.2.6 / finding #21).
• A blocker transitioning to a terminal status (done OR cancelled) flips the badge to Ready on the next render (revalidation); recategorizing a status live re-judges it.
• ReadinessBadge is a reusable presentational component (Epic 3/6 will reuse it), fed by the service verdict — no duplicate readiness logic in the page.
• Vitest (real Postgres): a blocked item reads "Blocked"; resolving the blocker reads "Ready"; cancelled-resolves; cross-workspace links never leak. shell-a11y stays green (the badge's state is conveyed by text, not color alone).

Context refs

• workflowsService.isReady + findBlockerStates (2.2.6) — the verdict + per-project terminal logic; this is its first production caller
• lib/repositories/workItemLinkRepository.ts (1.4.3) — link reads by kind + the workspaceId filter
• 1.5.5 Pill-tone AA rules (finding #35) — the badge must convey state by text, AA-safe tint
• 2.4.1's IssueDetailDto links — extend if the grouped-by-kind shape isn't already bundled