An existing PR title and body are provided in <existing_pr>, along with an auto-generated draft of the new commits in <draft> (grouped from conventional commit messages) and a list of changed files in <changed_files>. Update the PR title and body to reflect new commits. PRESERVATION RULES. Treat <existing_pr> as authoritative for all content it covers. Copy it verbatim — same wording, punctuation, capitalization, bullet order, section order, and section headers. Stylistic rewording is forbidden; factual correction from new commits is required. Title — rewrite ONLY if new commits change the Conventional Commits type or scope, OR if the title's claim is now inaccurate (e.g. the feature was renamed, narrowed, or reverted in new commits). Otherwise leave byte-identical. Existing bullet — rewrite ONLY if a new commit invalidates its claim (e.g. a later commit changes the described behavior). Remove ONLY if the change was fully reverted. Otherwise leave byte-identical — do NOT adjust phrasing, tense, punctuation (periods, dashes, em-dashes, commas), or capitalization. Section headers and section order — never change. Adding new content — append new bullets from new commits to the end of the matching existing section. Do not interleave with or reorder existing bullets. Add a new section only if new commits introduce a Conventional Commits type not already present. Intra-branch churn — if a new commit is a fix/refactor of code introduced earlier in this same branch, prefer updating the existing bullet in place (if its claim is now wrong) over adding a new bullet. Do not list the churn itself. If uncertain whether a change is warranted, prefer no change. Write a polished PR title in Conventional Commits format (feat:, fix:, refactor:, build:, chore:, docs:, style:, test:, perf:, ci:) on a single line and a refined body. Use ! (e.g. feat!:) when this PR would require a semver MAJOR version bump — i.e., it removes or incompatibly changes behavior that users of the current release rely on. Examples: removed command or flag, renamed required argument, changed output format that consumers parse. When in doubt, omit !. If the changed interface was introduced after the last tag (never shipped to consumers), it is not breaking — omit !. Keep the same section groupings (e.g. ### Features, ### Bug Fixes, ### Refactors, ### Docs). Only include sections that have changes. Some entries may be intra-branch churn (fixes or refactors of code introduced in this same PR) — consolidate or remove these rather than listing them as separate sections. Focus on the net, final effect of the PR relative to the base branch. Phrase each bullet as a practical outcome from the reader's perspective — describe what users or developers can now do, what no longer happens, or what improved — rather than listing implementation steps or internal file changes. After the change sections, add a ### Test Plan section with a short bullet list of manual steps a reviewer can follow to verify the changes work. Output ONLY the title and body. Do not wrap in code blocks or backticks.