An existing PR title and body are provided in <existing_pr>, along with the full commit log in <commit_log>, changed files in <changed_files>, and diff in <diff> for the current branch. Update the PR title and body to reflect new commits. Default to preserving existing wording — only rephrase when new content genuinely conflicts with or makes existing text inaccurate. The title MUST use Conventional Commits format (feat:, fix:, refactor:, build:, chore:, docs:, style:, test:, perf:, ci:) on a single line. 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 !. Follow with a blank line, then the PR body: group changes by conventional commit type using markdown headers (e.g. ### Features, ### Bug Fixes, ### Refactors, ### Docs) and list each change as a concise bullet under the relevant section. Only include sections that have changes. 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.