[OPER-QA-14 CORRECT] Split stalled qa-inbox-ui PR #296 into 4 landable stages (~500 LOC each)

feature_id: FEAT-studio-qa-projects
verify_cmd: pnpm --filter @operant/qa-inbox-ui build && pnpm --filter @operant/qa-inbox-ui test

## Context

PR #296 (`feat(qa-inbox-ui): @operant/qa-inbox-ui package + publish pipeline + purity gate (OPER-130)`) is currently open on `agent/oper-130-oper-qa-14-operant-qa-inbox-ui-npm-package-publish-pipeline-purity-gate` against `main` — 1,897 additions / 99 deletions across 18 files (net ~1,996 LOC). That exceeds every size band in `.claude/rules/pr-size-budget.md` and has been stalled long enough to block the Fiesta UAT loop, which cannot land its Portico mount (POR-771 `[POR-QA-2] Mount @operant/qa-inbox-ui at /qa/inbox`, IN_REVIEW) until the package is publishable.

OPER-130 was prematurely marked DONE in Ledger while the underlying PR remained open — a status/reality drift the earlier OPER-9D correction attempted to address (AWAITING_HUMAN) but did not resolve. This ticket splits PR #296 into four stack-friendly stages under ~500 LOC each so the package can actually land and unblock POR-771 → POR-772 → POR-773 → Fiesta UAT.

Proposed 4-stage split (stack-over-mega per `pr-size-budget.md`):

1. **Stage 1 — package skeleton + tsconfig + build pipeline.** Just the `package.json`, `tsconfig.json`, `tsup`/`tsc` build config, publish workflow, and the empty barrel exports. No React. Verifies the pipeline before any UI lands.
2. **Stage 2 — primitive UI (list, item, empty state) + purity gate.** The React components with zero Portico coupling and zero PHI-touching props, plus the purity-gate lint/CI check that rejects any import outside the package's declared surface.
3. **Stage 3 — client hooks + Studio API contract types.** `useInbox`, `useAssignment`, and the shared type surface for Studio ↔ package. No network code in the package itself — the consumer (Portico) supplies the fetcher.
4. **Stage 4 — publish trigger + version-bump automation + downstream consumer smoke test.** The workflow that actually pushes to GitHub Packages on merge, the version-bump automation, and a smoke test that consumes the published tag from a scratch consumer.

Each stage opens its own PR, stacked on the previous, sized within band, reviewable independently, and landable in order. Close PR #296 with a pointer to Stage 1 rather than force-pushing it into shape.

The earlier OPER-9D (AWAITING_HUMAN) attempt to publish `@operant-health/qa-inbox-ui` was premature — the package can't be published while its own PR won't merge. That ticket is superseded by this split.

References:
- PR https://github.com/operant-health/operant-studio/pull/296 (open, 18 files, +1897 -99)
- OPER-130 (DONE, incorrectly) — [OPER-QA-14] @operant/qa-inbox-ui NPM package + publish pipeline + purity gate
- OPER-9D (AWAITING_HUMAN) — supersede
- POR-771 (IN_REVIEW) — [POR-QA-2] Mount @operant/qa-inbox-ui
- POR-772 (IN_PROGRESS) — [POR-QA-3] Evidence writeback
- POR-773 (IN_REVIEW) — [POR-QA-4] Fiesta UAT seed data
- .claude/rules/pr-size-budget.md — stack-over-mega, XS/S/M caps

## Acceptance Criteria

- [ ] PR #296 closed with a comment pointing to Stage 1 PR (do not force-push #296 in place).
- [ ] 4 stacked PRs opened, each within the PR Size Budget (M cap or below), each with a green `/review` verdict.
- [ ] Stage 1 lands first, unblocking the pipeline; Stages 2–4 land in order.
- [ ] After Stage 4 lands, a published `@operant/qa-inbox-ui` tag exists in GitHub Packages consumable by POR-771.
- [ ] POR-771 unblocked (visible as a status change from IN_REVIEW to READY-to-merge, or successful merge).
- [ ] OPER-130 status corrected in Ledger post-merge (currently DONE while PR open — reconcile once Stage 4 lands).
- [ ] OPER-9D closed as superseded by this ticket.
- [ ] Body carries `verify_cmd: pnpm --filter @operant/qa-inbox-ui build && pnpm --filter @operant/qa-inbox-ui test` frontmatter.

verify_cmd: pnpm --filter @operant/qa-inbox-ui build && pnpm --filter @operant/qa-inbox-ui test