Breaking-change check before a release

I maintain {{package_name}}, currently at version {{current_version}}. Review this diff for changes that could break people who depend on it: ```diff {{diff}} ``` Check for: removed or renamed exports, functions, endpoints or fields; changed parameter order, types or defaults; stricter validation; changed error types or status codes; changed output shape; behaviour changes behind the same signature; raised minimum runtime or dependency versions. For each finding: what breaks, who is affected, and how to keep it backwards-compatible (deprecation, alias, optional parameter) if that's reasonable. Then recommend the next version number under semantic versioning (major / minor / patch) and draft the "Breaking changes" section of the release notes. If nothing breaks, say so.

Review this diff as a senior engineer who cares about correctness first, then clarity.

```diff
{{diff}}
```
Context: {{what_the_change_does}}

Output:
1. **Blocking issues** (bugs, security, data loss, race conditions) with line references and a suggested fix.
2. **Should fix** (error handling, edge cases, missing tests).
3. **Nits** (naming, style): max 5.
4. What's good about the change (1-2 lines).
If you're unsure whether something is a bug, say so and explain what would confirm it. Don't invent issues to fill sections.

Do a focused security review of this code for a {{app_type}} app:

```
{{code}}
```

Check specifically for: injection (SQL, command, template), XSS, auth/authorisation gaps (IDOR), secrets in code, unsafe deserialisation, SSRF, path traversal, missing rate limits, insecure defaults, and dependency risks you can see.
For each finding: severity (high/med/low), exploit scenario in one sentence, and the fix. If nothing is found in a category, say "none found" rather than speculating.

This code was written by an AI assistant. Review it with that in mind:

```
{{code}}
```

Look for typical AI-code problems: invented APIs or library functions that don't exist, outdated syntax, silently swallowed errors, over-engineering, duplicated helpers that already exist in the codebase, tests that don't really test anything, hard-coded values, and comments that don't match the code.
List each problem with the fix. Then rate: merge / merge after fixes / rewrite.