hir-94: per-recipient queue table on campaign detail

[jaredzwick]

The campaign detail page surfaced aggregate counts but a user could
not see which specific recipients were pending, sent, failed, or
bounced. The most common post-create question — "did my emails
actually go out?" — required a database query to answer.

• GET /api/campaigns/:id/queue: paginated per-recipient queue rows.
  Owner-checked (loads the campaign first to verify userId), then
  delegates to the existing getQueueEntriesByCampaign helper. Limit
  defaults 100, max 500; offset honored. Returns the columns a UI
  table needs (status / attempts / scheduled / sent / errorMessage)
  and omits raw send_log internals.
• /dashboard/campaigns/:id detail page: new "Recipients" section
  renders the queue rows in a table with status badge, attempts
  N/M, last-activity relative time, and a one-line error summary.
• src/lib/queueRowSummary.ts: pure helpers (queue-status badge
  label/tone, summarizeError that trims to a single line + ellipsis,
  formatRelativeTime that takes a fixed now for testability).

29 vitest specs in tests/int/queueRowSummary.int.spec.ts cover every
known + unknown queue status, error truncation (empty / multi-line /
CRLF / over-max with rounded ellipsis / trailing-whitespace strip /
custom max), and relative-time formatting (just-now band, past +
future across m/h/d/w with rounding, ISO string input, NaN/null
handling).

Stacked on hir-94/campaign-list-detail (PR-pending). No schema, no
migrations, no send-pipeline changes. tsc clean. test:int 139
passed (only pre-existing PAYLOAD_SECRET api.int.spec.ts fails).

Co-Authored-By: Paperclip noreply@paperclip.ing

Note: built on top of #19 (campaign-list-detail). Will rebase / become diffable on its own once #19 lands.

🤖 Generated with Claude Code

[jaredzwick]

CTO Review — LGTM

Solid feature addition. Three layers all consistent.

API layer (/api/campaigns/[id]/queue):

• Ownership check is correct and ordered correctly: fetch campaign first, then check userId. A missing campaign 404s before we even look at the requester — no timing oracle.
• clamp(parseInt(...), 1, 500) with Number.isNaN guard handles non-numeric inputs safely. Max 500 is reasonable for a UI table.
• Explicit field allowlist in the response map — doesn't accidentally surface internal fields if the DB schema grows.

UI layer (campaigns list + detail pages):

• cancelled = true cleanup in both useEffect hooks prevents stale-closure state updates on unmount — done correctly.
• Error objects carry .status through the promise chain for 404 vs. 5xx differentiation in the render.
• After successful campaign creation, router.push to the detail page — good UX, avoids the "success but now what?" dead end.

Helper libraries:

• summarizeError: raw.split(/\r?\n/, 1)[0] correctly handles both CRLF and LF line endings; the ?? '' is safe.
• formatRelativeTime: pure, no Intl.RelativeTimeFormat dependency (important for SSR/test environments), handles null/invalid dates gracefully.
• describeCampaignStatus / describeQueueStatus: sealed lookup tables with in guard + capitalize fallback — future-proof without being over-engineered.

No concerns. Ready to merge.