Turn a raw diff into a pull request description a reviewer can actually use

You are writing this pull request description for a reviewer who has not opened the diff yet and, realistically, will not read every changed line before deciding how carefully to review it. Write for that reader, not for yourself, having just read every line of the change.

TICKET OR CONTEXT
JIRA-4821 — zero-row CSV export throws a TypeError

HOW FAMILIAR IS THE LIKELY REVIEWER WITH THIS AREA OF THE CODE
The usual reviewer for this file has moved teams; the person reviewing this time has never touched the reports module.

TESTS THAT EXIST IN THIS AREA TODAY
tests/reports/export.spec.ts, 22 tests currently, run via npm run test -- reports/export

FORMAT
Summary — one or two sentences on what changed and why, in plain language, with no implementation detail yet.
Why — the problem or requirement that made this change necessary, linking the ticket above if one exists.
What changed — a bullet list grouped by area or feature, not by file; a reviewer thinks in features, not in a file tree, and a list organized by file forces them to reconstruct the feature-level story themselves.
How this was tested — exactly what was run, referencing the tests named above by name where relevant, and what the actual result was. Not 'tests pass' alone — name the suite and the count.
Risk and rollback — what is the actual blast radius if this change is wrong in production, and how would it be reverted or disabled quickly if so.
This deploys behind a feature flag already on for 5% of accounts; full rollout is a separate, later step.

CONSTRAINTS
- Do not describe the diff line by line. Describe intent and effect, at the level a reviewer who has not opened the files yet needs to decide where to look first.
- Do not claim a test was run or a case was verified manually unless you can name the specific thing that was actually run or checked.
- If the diff contains a change unrelated to the stated purpose above, call it out explicitly under What changed rather than omitting it because it does not fit the summary's narrative.
- If The usual reviewer for this file has moved teams; the person reviewing this time has never touched the reports module. indicates the reviewer is not deeply familiar with this area, add one extra sentence of orientation under Why — the context an unfamiliar reviewer needs to evaluate the change at all, not just what it does.
- Keep the whole description skimmable in under sixty seconds; it is a routing document for the reviewer's attention, not the full explanation of the change.
- If the diff touches a file with no existing test coverage named in tests/reports/export.spec.ts, 22 tests currently, run via npm run test -- reports/export, say so plainly under How this was tested rather than letting the section read as complete when part of the change is genuinely unverified by anything automated.

Paste the diff, or the output of git diff, below this line, unedited.