feat(papercuts): seed a worktree from a report so a fixer can reproduce it on real data #31

Part of #22. Wave 3. Blocked on #24. Also blocked on deciding where feat/ios-repro-harness lands.

Problem

Fixing #17 needed a manual recipe (documented in docs/fork/defect-resolution.md, "iPad and mobile"): snapshot the database with VACUUM INTO, export a thread, start the dev server with a replay file, run Metro, pair, open the thread. Every fixer re-derives it, and a papercut already names the thread. Agents fix bounded bugs with a reproduction far more often than from prose, and a failing test is worth more than a hypothesis.

What the code shows

• The replay harness (scripts/ios-repro/) exists only on the branch feat/ios-repro-harness, not on fork/prod.
• AGENTS.md ("Test data") already specifies how to seed a worktree from real data: VACUUM INTO into the worktree's .t3/userdata, copy in, never symlink, never write back.

Plan

1. t3 papercuts repro <id> --worktree <path>: seeds <path>/.t3/userdata from a read-only VACUUM INTO of the prod database, copies the report's record and trace slice into <path>/.t3/papercut-<id>/, and prints the dev command and the thread route for the report's thread.
2. For iPad and iPhone reports, also prints the replay steps from the harness (once it is on fork/prod).
3. Refuses a destination that is the live home or contains a symlink. Copy in, never out.

Acceptance

• Tests for the refusals. A seeded worktree opens the report's thread in a dev server.
• The fixer skill (feat(papercuts): /defect-session papercuts dispatches fixes from clusters #32) uses this as its first step.

Surfaces

CLI and scripts. Mobile reproduction continues to depend on #4 (instrumentable simulator).

Related

#22, #4, #24, #32.