[switch87]

What does this PR change?

Stacked on #554: it uses the job counter's variable offsets and the auto-advance hook from there. Until #554 lands, this diff also shows #554's commits; the CSV work starts at "feat: merge CSV rows into text templates".

Implements #528, Variable Text "Merge/CSV" as in LightBurn:

• Rows in templates.
  • A project stores the rows of a CSV file, so it stays self-contained, and keeps the file path for reloading.
  • Templates read a column by name, {csv["Name"]}, or by position, {csv[0]}; {row} is the 1-based row number.
  • A copy shows row current + variable offset, so a grid array lays out one row per copy. Copies past the last row show empty columns.
• Parsing. The delimiter (, ; tab |) is detected, and UTF-8 is read with or without BOM. The first row holds the column names unless every cell is a number.
• Commands. Load / reload and First / Previous / Next row all go through the undo history. Auto-advance after a finished job moves on by the number of copies; after the last row it stops with a notification instead of wrapping.
• Dialog. A CSV section in the dialog: file, reload, row navigation, a preview of the rows the next job uses, and a "copies needed" hint.
• Docs.

Out of scope, as agreed: editing CSV contents in Rayforge, encodings other than UTF-8, and an unattended one-job-per-row loop.

Why did you choose this specific architectural approach?

CSV rows are document data, like the job counter, so they live in the document next to it and reuse the same two mechanisms from #554:

• the per-workpiece variable offset (copy n shows row current + n);
• the "job finished" advance signal.

Templates receive the row as values through the same provider-params path as {counter}, so neither the CSV store nor the workpiece needs to know about template syntax.

The rows are copied into the project instead of re-reading the file at job time, so a moved or edited CSV can't silently change a job; Reload is explicit and undoable. The header heuristic ("all numbers → no header") replaces csv.Sniffer.has_header, which is unreliable on short files.

How did you manually test this locally?

1. Make a CSV with a Name column and 4 rows (Ann, Bob, Cas, Dirk). In the Variable Text / Job Counter dialog, load it: the dialog shows the columns and "4 rows".
2. A sketch with a text box {row}: {csv["Name"]}, arrayed to 3 copies: they show "1: Ann", "2: Bob", "3: Cas".
3. Run a job: the copies now show "4: Dirk" and two empty copies. The next job stops with "All 4 CSV rows have been used." Undo of Next / Previous and of loading works.
4. Edit the CSV on disk and press Reload: the new values appear and the current row is kept.

Checklist

• I am not an AI. I have manually read the code and understand it.
• I take full responsibility for the quality and architectural fit of
  this code.
• I agree to publish this code under the MIT license.

[github-actions]

This pull request was closed automatically because its description does not follow the pull request template. Problems found:

• section "What does this PR change?" is missing
• section "Why did you choose this specific architectural approach?" is missing
• section "How did you manually test this locally?" is missing
• section "Checklist" is missing

Please edit the pull request description to answer every section and to tick every checkbox; as soon as it complies, the pull request is reopened automatically. See CONTRIBUTING.md.

[switch87]

I'm putting this back to draft. Your comment on #554 from 18/10 changes the base for this PR: the document carries one job counter, not arbitrary variables, and CSV belongs in an app-global data source addon together with database and REST sources. Storing CSV rows in the project goes against that.

So I won't push the CSV rework I had prepared. Once #554 has landed I'll write down a few use cases and a proposal for such a data source addon first, as you suggested, and post it for review before writing code.