Implement to PR

1. Work out what to build. If you were given a GitHub issue, read it and its comments with gh issue view <number> --comments. Otherwise, build what we agreed on in this conversation. Don't add anything beyond that.
2. If you're on the main branch, create a new branch with a short name that describes the work. Leave unrelated local changes alone.
3. Build it the way the rest of the codebase does things, and follow the repository's instructions. Add or update tests where the change creates or alters behavior that users or callers rely on. When removing behavior, remove its tests rather than asserting its absence. While you build, keep checks narrow: lint and format only the files you changed, and run only the tests you wrote or that cover the code you changed. Save the full suites for the next step.
4. Once you think the work is complete, run the repository's full checks (formatting, linting, type checks, tests, and build) and read through the whole diff. If something fails, fix it using the same narrow checks, then run the full checks again. The work is done when everything the issue or conversation asked for works and every check passes. A check that already fails on the base branch for reasons unrelated to your change is not yours to fix; say so in the PR description instead of working around it. If a check needs a tool, runtime, or service that isn't installed here, such as a JDK, a database, or a browser, don't install system-level software without asking. Verify the change another way where you can, and report what didn't run in the PR description and your final response.
5. Commit, push, and open a pull request into the branch the user or repository instructions name, otherwise the default branch; gh repo view --json defaultBranchRef tells you which that is. Don't open it as a draft. Write the title and description as described below, save the description to a temporary file outside the repository, and pass it with --body-file.

If anything does not work as expected, don't hesitate to ask questions so we can get it working right. That includes an unclear request, a check that fails for a reason you can't find, and code that doesn't behave the way the issue assumes. Ask instead of guessing or working around the problem.

Never force-push or merge. When you're done, reply with the final response described below.

Pull request title and description

Write both from the committed diff, the issue, and the check results. Use the conversation only for the decisions and rejected alternatives behind the change, and only where the diff reflects them. The readers are engineers who review many pull requests. Use simple, everyday words, with technical terms only where they name something exactly, such as a file, command, or API. Write short paragraphs, put the most important point first, and use backticks for code identifiers. Keep the description proportional to the change.

Title: the outcome in simple words that a reviewer understands without opening the PR, such as "Retry failed webhook deliveries with backoff" rather than "Update webhook logic".

Description, in this order: