[TASK] Informative CSV parsing errors

### Description

We currently produce an error when a CSV form attachment is malformed, e.g. when a non-header row has more columns than the header row. The error we produce is useful enough for, say, a dev to inspect the CSV and (at least gradually) understand the behavior/likely intent/solution. But end users would benefit from errors with:

- More detail about what is specifically wrong. For instance:
- The source text of offending rows
- The actual columns we'd parse from that source text (if not for detecting an error)

Both of these details would be useful for users to get a sense of where the column boundaries should _actually be_. And it could at least hypothetically be used as a basis for a UI to resolve the issue (I believe I first encountered something like this in Excel's CSV import UI).

- Detail about more than one offending row in the same attachment. In the UI, we'd probably want some accommodations for many offending rows (e.g. capped height, scrollable, other similar affordances).

- Detail about more than one offending form attachment.

Note: each of the above considerations have implications for how we might want to model errors **in general**!

---

### Checklist
- [x] **Does it need UI/UX design?**
- [x] **Does it need API design?**
- [ ] **Does it need design around state flow?**
- [ ] **Does it need a test plan?**

---

### User Stories

- **As a** form designer/author (or any other role previewing forms before they're published),
**I want** more useful detail about problems with [CSV] form attachments,
**so that** I get a quicker/clearer understanding of how to resolve those problems.

---

### Design

- **Figma Link**: [Insert URL]
- **UI/UX Design Doc Link**: [Insert URL]
- **Technical Design Doc Links**: [Insert URL] (as noted above, this has implications for modeling of errors generally!)

---

### Additional Notes

- The issue which prompted this issue was a difference in behavior between Enketo and Web Forms, when a CSV has one or more rows with more columns than the header row:
- **Enketo:** silently drops trailing columns (or similar effective outcome)
- **Web Forms:** produces an error with a row number but little other detail
- The information detailed above would probably be sufficient, for a user who's familiar with the data but perhaps less technical, to get a sense of what went wrong
- In the long term, we could do even more useful form analysis to give users a sense of why these problems matter. For instance: in Enketo, with the form and attachment where the difference in behavior was observed/reported, offending rows are **dropped entirely** as options where a user would expect to find them! This was caused by a combination of where unquoted/extraneous commas were placed and form logic filtering items from columns which are mistakenly offset by those commas. All of this is statically knowable, and could be useful for users (and us too, when we're debugging issues like this).

---

### Related Issues

- #202

The issue names no implementation files, tests, or entry points, and explicitly calls for UI/UX and API design. Start by locating the CSV attachment parsing and error-modeling entry points; done means errors provide offending row source text and parsed columns, support multiple offending rows and attachments, and have a defined UI/API design.

Written by the indexing model from the issue text.