Work PR title and description

Draft one title and one body for a pull request the user opens themselves. Drafting is the whole job: creating the PR, pushing, and setting review state stay with the user.

1. Collect the change: the current branch name, git log <default-branch>..HEAD --oneline, and the diff behind those commits. Read every issue the branch name or the commit messages reference:

   df-ti <issue-number>
   

   Run it once per issue number. When no issue number appears anywhere, ask which issues this PR relates to. Done when the problem, the solution, and the full issue list are known.

2. Settle whether the PR is ready for review, asking the user when the conversation has not already said. Done when ready or not-ready is decided.

3. Draft the title: one line naming the change from the reader's side, specific enough to tell it apart from the other open PRs. Prefix WIP: when step 2 landed on not ready. Done when the title names the actual change, and carries the prefix only in the not-ready case.

4. Draft the body: exactly two paragraphs, the first on the problem, the second on the solution, plus the reference lines from step 5. Write plain text, full sentences, present tense, with numbered points when a list is needed. Skip em dashes, en dashes, hyphens as punctuation, and hyphenated compounds (write "per workspace", not "workspace-scoped"). Everything that is neither the problem nor the solution travels to step 7 instead: caveats, known gaps, test evidence, follow-up work, and anything a product owner still has to confirm. Done when the body is two paragraphs, and a reviewer who has not read the diff can say what was wrong and what the change does about it.

5. Close the body with one reference line per issue from step 1, each on its own line. An issue this PR addresses gets a lowercase resolves: line with a colon; an issue mentioned only for context, which this PR does not address, gets a Related to line instead: