fix(drivers): preserve BIGINT precision past JS Number.MAX_SAFE_INTEGER

[NewtTheWolf]

Summary

• Closes [Bug]: When using values above 2^53, the accuracy of the interface display is lost #210. BIGINT values above 2^53 - 1 (e.g. snowflake ids like 844197938335842304) lost their last digits in the UI because the read path emitted them as JSON numbers and the frontend's JSON.parse rounds to the nearest IEEE 754 double.
• New drivers::common::safe_int helper emits i64/u64 as a JSON string only when the value falls outside JS's safe integer range; smaller values stay native numbers, so the wire format for the 99% case is byte-identical to before.
• Wired through MySQL (u64/i64 scalar fallback), Postgres (INT8, XID8, MONEY), and SQLite (INTEGER).
• Mirror change on the write-back side: a JSON string that parses cleanly as an i64 outside the safe range is bound as a native integer, so editing or deleting by a large bigint PK still matches. Postgres wraps the bind in CAST AS bigint to satisfy tokio-postgres' strict type checking; MySQL and SQLite rely on their implicit numeric coercion.
• 17 new unit tests covering boundary cases and the snowflake roundtrip. Full driver test suite: 297 passed.
• Demo seed bigint_demo added to MySQL and Postgres init scripts so the boundary cases are reproducible without ad-hoc SQL (mirrors the text_demo / json_demo pattern).

Behaviour notes

• Sort and filter are unaffected because both run server-side. handleSort in Editor.tsx builds an ORDER BY clause and the filter toolbar builds a WHERE clause; the comparison happens in the database against the native BIGINT column, never in JS. The grid has no client-side global/quick filter that could trip over a mixed number/string column.
• Cells that now arrive as strings are still rendered identically (the renderer already accepts either shape), and the row editor sends them back as strings, which the write-back path translates back to i64 before binding.

Test plan

• cargo test --lib drivers → 297 passed
• cargo build --lib clean, no new clippy warnings on touched files
• MySQL manual test (bigint_demo table):
  • Read: snowflake 844197938335842304 displays exactly (was …842300)
  • Read: i64::MAX 9223372036854775807 displays exactly
  • Read: u64 18446744073709551614 (BIGINT UNSIGNED above i64::MAX) displays exactly
  • Boundary: 42 and 9007199254740991 stay JSON numbers (sortable numerically)
  • Write UPDATE of non-PK column on the snowflake row matches exactly one row
  • INSERT new row with id = 7777777777777777777 succeeds
• Postgres manual test (bigint_demo table):
  • All read cases pass for BIGINT, XID8 and MONEY columns
  • UPDATE note on snowflake PK row → exactly one row updated
  • UPDATE amount on snowflake row → bigint outside safe range round-trips through SET
  • INSERT new row with id = 7777777777777777777 succeeds

[debba]

Looks good and thanks for demo seed :)