Turn a raw CSV into a statistics report with charts, code included

Use the analysis tool (run actual code against the data) for this — do not eyeball the data and describe a conclusion from memory. Every number in your report should be something the code actually computed, and I should be able to see the code that computed it.

DATASET
A CSV export of 2,400 customer feedback survey responses with columns: response_id, submitted_at, nps_score, plan_tier, region, free_text_comment. The data itself is attached or pasted below. If the dataset includes a column whose meaning is not obvious from its header alone, state your interpretation of what it represents before using it in any calculation, so a wrong assumption about a column's meaning is visible rather than baked silently into every downstream number.

QUESTIONS TO ANSWER
1. Does NPS score differ meaningfully by plan tier? 2. Has average NPS trended up or down over the last two quarters? 3. Is there a regional pattern in low scores (0-6) specifically?

AUDIENCE FOR THIS REPORT
A product manager who understands averages and basic charts but is not a statistician — avoid unexplained jargon like 'p-value' or 'confidence interval' without a one-clause plain definition.
Calibrate statistical vocabulary and how much methodology detail to spell out versus summarize based on this audience.

WHAT TO PRODUCE
1. For each question, the direct answer stated first, followed by the actual code that produced it — real, runnable code, not pseudocode or a narrated description of a calculation. Show intermediate results for any multi-step calculation, not just the final number — if computing a growth rate requires first aggregating by month, show the aggregated table, not just the rate that came out the other end.
2. At least 3 charts that would help someone else understand the pattern, not just the number — choose the chart type that fits the data shape (distribution, trend over time, comparison across categories), and say in one sentence why that chart type was the right choice for this particular question, not just a default.
3. A DATA QUALITY section: missing values, obvious outliers, duplicate rows, or inconsistent formatting the code encountered while running — say exactly how each was handled (dropped, imputed, kept as-is) rather than silently making a choice inside the code with no comment on it.
4. A section on statistical caveats: sample size, whether any correlation found could plausibly be explained by a confound not in this dataset, whether the pattern found is large enough to matter practically or just large enough to be visible in a chart, and whether it would likely hold on a larger or different sample or is plausibly a quirk of this specific dataset's size.

CONSTRAINTS
- If a question can't actually be answered from the columns present in the dataset, say so explicitly rather than computing something adjacent and presenting it as if it answered the original question.
- Do not round or simplify a number in the narrative differently from what the code actually output — if the code says 23.7%, the sentence says 23.7%, not "about a quarter," unless rounding is explicitly requested.
- If there's an industry-benchmark NPS figure commonly cited for this product category, note it as external context, clearly separated from anything computed from this dataset.

AFTER THE REPORT
In two sentences, name the single finding you'd flag first to someone with five minutes to read this, and the one thing about the data that makes you least confident in that finding — a real limitation, not a boilerplate disclaimer.