xls: linear grid assembly; sqlite3: exact 64-bit integer decode

[Hugoberry]

Two independent reader improvements, each validated with a before/after A/B on the repo's own perf harness (run-odbc-benchmark.ps1 / run-script-benchmark.ps1, median of runs, warmup discarded, overhead-subtracted, with unchanged readers as thermal controls).

1. xls — linear grid assembly (performance)

GridFromCells used the old superlinear design PERF.md documents as the original xlsb bottleneck: a Record.FromList row map keyed by row number (record lookup cost grows with field count), a List.Accumulate row builder (O(ncols²) append per row), and a Table.FromRecords → Table.Group → Table.ToRecords round-trip.

Replaced with xlsb's proven buffered run-cursor assembly: cells stay in one List.Buffer, rows are kept as [A, B) index ranges (indexing cells{i} instead of List.Range avoids the quadratic Skip walk), a single pointer-walk fills each row in column order, and an unordered fallback sorts only when a malformed file has out-of-order/repeated row headers.

Measured: driverless eval 1,871 ms → 843 ms (−55%) on the 24k-row ACE fixture; no functional-test changes.

2. sqlite3 — exact 64-bit integer decode (correctness, perf-neutral)

DecodeValue now dispatches integer serial types to hoisted big-endian BinaryFormat readers (SignedInteger16/32/64 for st 2/4/6; a byte + manual sign for st 1), keeping the accumulate helper only for the 3- and 6-byte widths BinaryFormat can't express, with precomputed sign constants.

The 8-byte path via SignedInteger64 decodes the full signed 64-bit range exactly, fixing the documented precision loss above 2^53. The types fixture (which deliberately stores 2^53+1 and the int64 extremes) is rebaselined to the true values, and the precision notes in the reader header, README and test doc are corrected — plus gpkg's and mbtiles', which inherit this core.

Measured: perf-neutral. The bulk fixture stores its integers as 0/1 serial-type specials (st 8/9), so st 1–6 never runs; the A/B confirmed no change (87.2 s ≈ 90 s before).

Reviewer note — what was deliberately not included

The audit's issue 2 also proposed rewriting DecodeRecord (per-row header walk) as a List.Generate cursor. The A/B showed that regressed sqlite3 by +67% (86 s → 144 s on the 4M-row fixture, rippling +17% to gpkg/mbtiles): List.Generate's per-step overhead is paid on every row, and the "O(ncols²)" it targets is negligible at 4 columns. DecodeRecord is therefore left as the original recursive walk. Only the perf-neutral, correctness-improving DecodeValue half is kept.