Isolate d1 import sqlite3 runs from user config

[no-itsbackpack]

Summary

A user hit this during a D1 import:

Import failed: count sqlite staging rows: expected integer

The cause is that the sqlite3 shell loads ~/.sqliterc even for one-shot invocations. If that file turns on headers or column mode, the output of SELECT COUNT(*) is no longer a bare integer and the import verification fails. Reproduced locally: with .headers on in ~/.sqliterc, sqlite3 db "SELECT COUNT(*) FROM t" prints COUNT(*) before the number, which is exactly what broke the parse. Setting $HOME does not help because sqlite3 finds the rc file through the passwd database.

Changes

• All sqlite3 invocations in the d1 import (row counts, fingerprints, sampling, chunked dump loading) now go through a helper that passes -batch -noheader -init /dev/null, so output is always plain list mode regardless of the user's .sqliterc.
• Replaced fmt.Sscanf("%d") with strict strconv.ParseInt. Sscanf accepts trailing garbage ("3 rows" parses as 3) and its "expected integer" error carries no context, which is why this bug was hard to diagnose from the report. Parse errors now quote the actual output.
• runSQLiteQuery no longer parses CombinedOutput. sqlite3 can exit 0 while printing warnings to stderr (WAL recovery, lock warnings), and those bytes were being mixed into output we split and compare. Stdout is parsed, stderr is reported only on failure.
• Failed counts now include sqlite3's stderr instead of just "exit status 1".
• SQL identifiers are quoted with proper SQL escaping (" doubled) instead of Go's %q, which produces invalid SQL for names containing quotes or backslashes.

Testing

• Reproduced the original failure with a .sqliterc containing .headers on and .mode column, then confirmed the hermetic flags produce clean output with the same rc file in place.
• go test ./internal/import/d1/ passes, go vet and gofmt clean.