Summary

Fixes a bug where SQLite code generation produced truncated or corrupt
output whenever the source .sql file contained a non-ASCII character
(em-dash, accented letters, etc.).

The bug

Given a query with a multi-byte character in a comment (here the é in
"café", which is 2 bytes in UTF-8):

-- name: GetItem :one
-- Lookup used by the café menu screen
SELECT id, name FROM items WHERE id = ?;

sqlc generated a truncated SQL constant, dropping the trailing ?:

const getItem = `-- name: GetItem :one
SELECT id, name FROM items WHERE id =
`

In queries that use sqlc.arg() or SELECT *, the misaligned offsets
caused edits to land at the wrong byte positions and produced SQL that
fails to parse (e.g. SEid ...). There was no error at generate time —
the corruption was silent.

Root cause

antlr's InputStream stores the input as a []rune and reports all
token positions as rune indices. The rest of sqlc, shared with the
Postgres and MySQL engines, treats query offsets as byte offsets
into the original source:

• source.Pluck slices the raw SQL for each statement
• source.Mutate applies parameter / star-expansion edits

For ASCII, rune index == byte offset, so the bug never surfaced. A
multi-byte rune (em-dash = 3 bytes, 1 rune) makes every later rune
index lag its true byte offset, truncating the statement slice and
shifting every edit. Postgres and MySQL are unaffected because they get
byte offsets from libpg_query and TiDB.

The fix

Confined to the SQLite engine. We build a rune-index → byte-offset table
for the source and translate offsets at the point they are produced, so
a rune-based offset never escapes the parser:

• parse.go converts the statement's StmtLocation / StmtLen and
  threads the table into the converter (cc.convertPos).
• convert.go routes every node Location through a single cc.pos
  helper instead of using the raw antlr token offset.

By the time the AST leaves the parser, all offsets are byte offsets,
matching the invariant the other engines already satisfy. The
translation lives where the offsets originate, so there is no separate
post-processing pass and no reflection.

Testing

• New regression test internal/engine/sqlite/parse_test.go (fails
  before the fix, passes after).
• Verified sqlc generate end-to-end on the query above and on a harder
  case (multi-byte string literal before sqlc.arg() params +
  SELECT *); both are correct after the fix, and the latter produced
  corrupt SQL before it.