Run Claude Code's structured security review discipline before every merge

You are performing a security review, mirroring the discipline behind Claude Code's own security-review command — find what an attacker would actually try, not confirm that the intended feature works as described. Flag findings. Do not silently fix anything in this pass, even a one-line fix that feels obviously safe to make.

SCOPE
The new /api/users/[id]/export route and the auth middleware wrapping it, added in this pull request.

THREAT CONTEXT
This endpoint returns a full data export, so an authorization bypass here is a data-breach-severity issue, not just an inconvenience.

SENSITIVE DATA IN SCOPE
The export includes email, billing address, and the last four digits of a stored card.

DEPLOYMENT CONTEXT
Ships directly to production behind the standard auth middleware, with no additional WAF rule in front of it.

REVIEW CATEGORIES — GO THROUGH EVERY ONE, DO NOT SKIP SILENTLY
1. Injection — SQL, NoSQL, command, template, or log injection anywhere user-controlled input reaches a query, a shell call, a template renderer, or a log line that is later parsed.
2. Authentication and authorization — missing auth checks, broken object-level authorization such as one user accessing another user's resource by changing an identifier in a request, or any privilege-escalation path.
3. Secrets and sensitive data — API keys, tokens, credentials, or personal data hardcoded, logged, committed in a fixture, or returned in an API response that does not need to include it.
4. Input validation and deserialization — unbounded input size, unvalidated file uploads, unsafe deserialization of anything user-controlled.
5. Server-side request forgery and outbound calls — does any user-controlled input influence a URL, hostname, or file path fetched or opened server-side?
6. Dependency and supply-chain risk — any new or changed dependency with a known-bad reputation, an unpinned version, or a maintainer change worth a second look.
7. Output handling — unescaped output enabling cross-site scripting, unsafe raw HTML rendering, or an unvalidated redirect target.

OUTPUT FORMAT
For each category: either CLEAR, or FINDING with a severity of Low, Medium, High, or Critical, the exact file and line, a concrete exploit scenario stating the specific input or request that triggers it rather than a vague 'this could be unsafe', and a suggested fix presented as a recommendation for a human to apply, not applied automatically in this pass.

CONSTRAINTS
- Do not report a theoretical concern as a finding unless a concrete triggering input can be stated. A pattern that merely looks unusual is not automatically a vulnerability.
- Do not downgrade a real finding into a soft best-practice suggestion to make the review read cleaner. Severity reflects actual exploitability, not how the finding will be received.
- If nothing in a category applies, say CLEAR explicitly rather than omitting the category from the output — an omitted category and a checked-clear category look identical to a reader unless the omission is visible.
- Rank findings by severity in a final summary, and state which single finding, if only one could be fixed before merge, would matter most and why.

This is a review, not a remediation pass — do not modify any code. Paste the diff or files to review below this line.