CSV import reports every row number shifted by one

When a bulk CSV import partially fails, the API tells the user which "row" had a problem so they can go fix it in their spreadsheet and re-upload. Right now every reported row number is one less than the actual line in the file the user uploaded. A user who trusts the error message ("row 3 has a bad email") will open their spreadsheet, "fix" the wrong line, re-upload, and get the exact same error again -- a frustrating, support-ticket-generating loop for what should be a simple self-service correction. For a bulk-import feature, accurate row reporting isn't cosmetic -- it's the entire value of returning per-row errors instead of one opaque failure.

import_contacts() numbers rows via enumerate(reader, start=1). Since the CSV header occupies line 1 of the file, the first data row is line 2 -- but the loop reports it as "row 1", the second data row as "row 2", and so on: every reported row number is off by exactly one relative to the actual line number in the uploaded file.

printf 'name,phone,email,groups\nGood Row,555-1000,good@example.com,\n,555-2000,bad@example.com,\n' > /tmp/contacts.csv curl -s -X POST http://127.0.0.1:5000/api/contacts/import -F "file=@/tmp/contacts.csv;type=text/csv"

results[0]["row"] is reported as 1, but "Good Row" is on line 2 of the file

(line 1 is the header). Expected: results[0]["row"] == 2

enumerate(iterable, start=N) is a one-argument decision that silently shifts every downstream index. Here the comment right above the loop (# header is row 1) documents the intended numbering, but the start= value contradicts its own comment -- the kind of drift that happens when someone "simplifies" a loop and doesn't re-derive the correct offset from first principles.

Look at the for row_number, row in enumerate(reader, ...) line in import_contacts(). Re-derive the offset from the comment already sitting right above it: if the header is line 1, what should start= be so the first data row is numbered correctly?