feat(liveness): record GitHub PR work-product progress (BLO-19566)

[kkroo]

Thinking Path

• Paperclip is the control plane that gives operators auditably visible progress from autonomous agents.
• Productivity reviews decide whether an assigned issue appears to be progressing, so their evidence must include real delivery signals.
• A linked GitHub PR is an important delivery signal, but current master neither records it as an issue work product nor exposes it to productivity evidence.
• App-authored #920 established the needed direction but cannot take the protected merge path and still has an exact-head same-second lifecycle ambiguity.
• GitHub updated_at is second-resolution, so distinct close/reopen deliveries can be causally ambiguous even after normal stale-delivery ordering.
• This independent successor records trusted PR work products, preserves source chronology, and reconciles only ambiguous lifecycle cases with GitHub's authoritative current state.
• The result is that real PR progress is visible without letting delayed, ambiguous, or manually edited evidence manufacture liveness.

Linked Issues or Issue Description

Refs #920, the App-authored predecessor. This is an independent kkroo successor for its still-unmerged PR-work-product scope; it does not modify, close, or merge the original.

Refs BLO-19566. The issue's remaining acceptance criterion is to make a referenced GitHub PR visible as trustworthy productivity evidence.

Duplicate search: current GitHub search finds only #920 and the already-merged related #905. Current master has no PR work-product mapper/service or external-identity migration. The generic Artifacts & Work Products roadmap item does not provide this equivalent implementation.

What Changed

• Add a pull_request work-product mapper and an external-identity unique index/migration that deterministically reconciles pre-existing duplicates before enforcing uniqueness.
• Upsert trusted GitHub PR evidence for every referenced (and previously linked) Paperclip issue on pull-request webhooks, including terminal and unassigned issues.
• Preserve GitHub event chronology, reject delayed/redelivered state regression, and resolve distinct same-second lifecycle payloads through a single authoritative GitHub App read; unavailable authority leaves the evidence pending and non-creditable.
• Include only trusted, verified PR evidence in productivity review output; count fresh ready/draft/merged PRs while excluding closed, stale, spoofed, manually edited, URL-less, and pending-ambiguity rows.
• Add focused migration, mapping, webhook, GitHub App, productivity, and actor-provenance regression coverage.

Verification

Run from this branch after rebasing onto origin/master at 08b6f44916103b624744dff6453997f85e67265b:

pnpm --filter @paperclipai/db typecheck
pnpm --filter @paperclipai/server typecheck
pnpm --filter @paperclipai/server exec vitest run \
  src/__tests__/pull-request-work-products.test.ts \
  src/__tests__/github-app-auth.test.ts --reporter=dot --silent

Passed focused database-backed coverage:

pnpm --filter @paperclipai/db exec vitest run \
  src/issue-work-products-external-identity-migration.test.ts --reporter=verbose
pnpm --filter @paperclipai/server exec vitest run \
  src/__tests__/productivity-review-service.test.ts -t 'pull-request evidence' --reporter=verbose --silent
pnpm --filter @paperclipai/server exec vitest run \
  src/__tests__/github-webhook.test.ts -t 'pull_request work products' --reporter=verbose --silent
pnpm --filter @paperclipai/server exec vitest run \
  src/__tests__/issue-agent-mutation-ownership-routes.test.ts -t 'clears webhook provenance' --reporter=verbose --silent

Results: migration 1/1, productivity evidence 12/12, webhook work products 17/17, actor-provenance 1/1, and mapper/GitHub App 57/57 passed.

Risks

• The additive migration clears only the duplicate rows' external_id, preserving their work-product records and recording the former identity in metadata before creating the partial unique index.
• An authoritative GitHub read occurs only for distinct lifecycle payloads sharing one source timestamp second. If GitHub is unavailable, the evidence stays pending and productivity credit fails closed rather than guessing an order.
• Webhook persistence remains best-effort, so a database failure cannot block normal GitHub wake handling; the consequence is missing evidence until a later delivery, not an incorrect success signal.

Model Used

OpenAI Codex, GPT-5-based deployment (the exact deployment model ID and context window are not exposed in this environment), with reasoning, tool use, code execution, GitHub CLI inspection, and targeted test execution.

Checklist

• I have included a thinking path that traces from project context to this change
• I have specified the model used (with version and capability details)
• I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work
• I have searched GitHub for duplicate or related PRs and linked them above
• I have either (a) linked existing issues with Fixes: # / Closes # / Refs # OR (b) described the issue in-PR following the relevant issue template
• I have run tests locally and they pass
• I have added or updated tests where applicable
• If this change affects the UI, I have included before/after screenshots — n/a, server/database only
• I have updated relevant documentation to reflect my changes — n/a, no public command or operator-facing contract changed; migration and safety rationale are covered by code and tests
• I have considered and documented any risks above
• All Paperclip CI gates are green — pending first draft CI run
• Greptile is 5/5 with no open P2s, recommendations, or follow-ups — pending review
• I will address all Greptile and reviewer comments before requesting merge

[allyblockcast]

🔗 Paperclip issue: BLO-19566

[allyblockcast]

🔗 Paperclip issue: BLO-19566

[kkroo]

Closing as stale — this draft can no longer be landed as a diff.

Measured against master ac91e966:

• 803 commits behind
• 11 conflicting file(s) (git merge-tree --write-tree)

At that distance the surrounding code has moved out from under the patch, so "resolve the conflicts" would mean rewriting it against a codebase it was never written for — not merging it. Reopening is cheap if the branch is still wanted; the commits are untouched.

Closing the PR does not close the underlying issue. Where this PR referenced a BLO issue, that issue remains the record of intent and the place to re-implement from, against current master.

No judgement here on whether the original problem still exists — I did not verify that per-PR, and it should be re-checked before any re-implementation, since some of these may already have been fixed independently.