Turn Claude Code into a consistent code reviewer instead of a vibes check

You are reviewing this change as the senior engineer whose name goes on the approval, not as a friendly first reader. Cite exact file names and line numbers for every claim. Do not soften an actual defect into 'just a suggestion' if it should actually block the merge — say plainly whether it blocks.

CHANGE UNDER REVIEW
Adds a bulk CSV export endpoint at /api/reports/export that streams up to 50,000 rows.

WHAT THIS CHANGE CLAIMS TO DO
The PR description says this should let an admin export a full report without timing out, using a streaming response instead of building the whole CSV in memory.

TEAM CONVENTIONS THIS DIFF SHOULD MATCH
This codebase always wraps a streamed response in the existing withStreamingResponse helper in lib/http/streaming.ts rather than writing to the response object directly.

KNOWN RISK AREAS FROM PAST INCIDENTS
The team has been burned before by an export endpoint holding a database connection open for the full stream duration.

REVIEW CATEGORIES
1. Correctness — does the logic do what the stated intent above claims? Any off-by-one, race condition, null or undefined path, or edge case the tests do not cover?
2. Security — injection risk, authorization gaps, secrets in code, unsafe deserialization, or unvalidated input crossing a trust boundary.
3. Tests — do the tests exercise the actual changed behavior, or just re-assert what the implementation already does? Name any case the diff clearly needed but did not add.
4. Readability and naming — would an engineer with no memory of writing this understand it in six months without asking the author?
5. Scope — does this diff do only what the stated intent says, or is there an unrelated change bundled in that was never mentioned?
6. Performance — any new N+1 query, unbounded loop, or blocking call introduced on a path that runs on every export click, currently a few dozen times per day, expected to grow with a new admin dashboard launch?

OUTPUT FORMAT
For each category: PASS, CONCERN, or BLOCKING, one line of reasoning, and a file and line reference for anything not PASS.
End with one verdict — APPROVE, APPROVE WITH COMMENTS, or REQUEST CHANGES — and a one-sentence justification. No verdict is valid without one.

CONSTRAINTS
- A CONCERN that you would personally block on if this were your own team is a BLOCKING, not a CONCERN softened to avoid conflict. Rate honestly, not diplomatically.
- If two categories point to the same root cause, such as a missing test also being a correctness risk, note the link rather than repeating the same explanation twice as if they were independent findings.
- Do not raise a finding purely about style if it matches an existing, unremarked-on pattern already common elsewhere in this codebase — flag genuine inconsistency, not personal preference.
- Read This codebase always wraps a streamed response in the existing withStreamingResponse helper in lib/http/streaming.ts rather than writing to the response object directly. before judging readability or scope, since a pattern that looks like an inconsistency to a reviewer unfamiliar with this codebase may in fact be the established local convention, and the reverse is just as costly: waving through a genuine departure from convention because it superficially resembles something seen elsewhere.

Paste the diff or files under review below this line, unedited.