Run a security and secrets pass with Cursor's Agent mode before a PR goes up, not after

Review the changes in this session for security issues before this goes into a PR. Treat this as a dedicated security pass, not a general code review — you're looking specifically for the categories below, not restating style feedback.

FILES CHANGED THIS SESSION
app/api/reports/export/route.ts, lib/reports/buildQuery.ts, lib/reports/generatePdf.ts

SPECIFIC RISK CATEGORIES TO CHECK
SQL injection risk in buildQuery.ts since it assembles a query from report filter params; path traversal risk in generatePdf.ts since it writes a file using a user-supplied report name.

TRUST BOUNDARY FOR THIS CHANGE
This endpoint is reachable by any authenticated user, including the lowest-privilege role — report filter params and the report name are both fully attacker-controlled from an authenticated session.

CHECK FOR, SPECIFICALLY
1. Any hardcoded secret, API key, token, or credential — including one that looks like a placeholder but would still work if accidentally left in (a real-format key with a name like "test" or "example" is still a real credential if it's actually valid).
2. Any place user-supplied input reaches a database query, shell command, file path, or template render without validation or parameterization — name the specific input and the specific sink it reaches.
3. Any place this change trusts data from the client (a request body, a query param, a cookie) to make an authorization decision, rather than re-deriving that decision server-side from something the client can't forge.
4. Any new dependency added in this change, and whether it's from a source you'd expect for this ecosystem or something unusual worth a second look before it's trusted with the access this code gives it.

For each finding: cite the file and line, classify it as Critical / High / Medium / Low based on This endpoint is reachable by any authenticated user, including the lowest-privilege role — report filter params and the report name are both fully attacker-controlled from an authenticated session. — the same pattern is a different severity depending on whether the input crossing it is actually attacker-controlled here — and state the specific fix, not just the problem.

Do not propose a fix that merely suppresses the symptom — escaping a string to stop a linter warning without actually parameterizing the underlying query is not a fix, it's the same vulnerability with a quieter warning. If you're not sure a proposed fix actually closes the risk rather than just changing its shape, say so explicitly rather than presenting it with unearned confidence.