mz-deploy: report statement offsets in raw-file coordinates (DEX-60)

[sjwiesman]

Statement byte offsets were computed against the variable-resolved SQL,
but every consumer (the CLI diagnostic renderer and the LSP) reads the
raw file. A :var whose value differs in length from the reference
shifted all later offsets, so diagnostics pointed at the wrong span and
could miss the token entirely. Map each offset back to the raw file with
the substitution table at parse time, fixing both consumers at the
source.

Ticket: DEX-60

Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com

🤖 Generated with Claude Code

https://claude.ai/code/session_01VAcnVpSQi8ZgF5LekQRwvw

[tonydu-mz]

One follow-up worth adding: the clamp branch in resolved_to_original (offset inside a substitution's resolved span → returns sub.original_start) has no test, and it's the one non-obvious path here.

It's reachable when a variable's value contains a ;: the substitution injects a statement separator that isn't in the raw file, so the following statement starts inside the substitution's resolved span. Worth a test that a value like :x → 1; SELECT 2 maps that second statement's byte_offset back to the :x reference and stays in-bounds of the raw file. This is the branch most likely to regress silently under a future refactor.

Lower priority, also uncovered: multiple substitutions before a statement (cumulative delta), and a resolved + unresolved variable interleaved (delta staying correct across a reference that isn't recorded as a substitution).

[sjwiesman]

@tonydu-mz pushed a fix

[tonydu-mz]

will look into this tonight