Consider publishing specs and plans as pull requests instead of issue uploads

[rochecompaan]

Summary

Consider publishing specs and plans as pull requests instead of uploading them
to the issue, so reviewers can view planning artifacts as part of a PR and
hold discussion there.

Problems with the current mechanism

Specs and plans are published to the issue with patchmill set-spec and
patchmill set-plan, which attach them to the issue as comments/attachments.

• Clumsy to view: artifacts appear inline in issue comment bodies. Long
  documents buried in a comment thread are hard to navigate, and each revision
  adds another comment rather than updating a single current view.
• No checkout: the artifacts are not on a branch. A reviewer cannot check
  them out locally, open them in an editor, or run tooling against them.
• No real review: issue comments do not support line-level review
  comments, suggestions, or diff views between revisions. Feedback on a
  specific section means quoting it in a new comment.
• No review state: there is no approval mechanism comparable to PR
  reviews; approval is tracked indirectly through labels.

What a PR would give us

• The spec and plan live as files on a branch, viewable in the PR files view
  with full Markdown rendering.
• Line-level review comments and threaded discussion on the exact passage
  under debate.
• Reviewers can check out the branch locally.
• Revision history through commits; changes between rounds are visible as
  diffs.
• Native approval state via PR reviews, which could replace or complement the
  current label-based approval.

Questions to explore

• How does a planning PR relate to the issue and to the later implementation
  PR? One PR that starts with planning artifacts and grows implementation
  commits, or separate PRs?
• What happens to patchmill set-spec / set-plan and the existing
  attachment envelope/checksum validation?
• How do unattended runs create and update these PRs without human input?
• How does this interact with Add adversarial spec and plan review to planning #177 (adversarial spec/plan review) and Attach show-me visualizations of the spec and plan to planning output #179
  (show-me visualizations, which would get a natural home as committed HTML
  artifacts on the branch)?

Delivery overview

This issue is the design and coordination umbrella. Implementation is split into independently reviewable sub-issues with explicit dependencies. The umbrella is marked agent-unsuitable; agents should claim only an unblocked child issue.

• Define provider-neutral planning pull request foundations #184 — Provider-neutral pull request, phase-plan, and workspace foundations
• Implement the GitHub planning pull request adapter #185 — GitHub pull request adapter
• Implement the Forgejo planning pull request adapter #186 — Forgejo pull request adapter
• Add durable planning state and pull request workspaces #187 — Durable state, lock, and Git workspaces
• Execute and publish planning pull request phases #188 — Planning phase execution, publication, and reconciliation
• Integrate planning phases and require implementation pull requests #189 — Pipeline integration and implementation pull request enforcement
• Migrate and document the planning pull request workflow #190 — Compatibility, documentation, and final acceptance

Dependency order

#184 is the first delivery slice. After it closes, #185, #186, and #187 can proceed in parallel. They converge on #188, followed by #189 and #190.

GitHub native sub-issue and blocked-by relationships are authoritative. The blocked labels mirror those dependencies for Patchmill triage.

Acceptance criteria

• A decision, with trade-offs recorded, on whether planning artifacts move to
  PRs.
• If adopted: a design for the planning-PR workflow covering the questions
  above.