Prepared-protocol BIGINT returned as JS bigint under perry-native but number under Node (breaks JSON.stringify)

[proggeramlug]

Summary

A BIGINT column read via the prepared (parameterized) protocol is returned as a JS bigint when the program is compiled with perry, but as a number under Node.js — for the same in-range value (1). The text protocol returns number on both. The bigint type then breaks JSON.stringify / fast-json-stringify (fields surface as null in HTTP responses).

Repro

import { connect } from '@perryts/mysql';
const c = await connect('mysql://root@127.0.0.1:3306/bug_bigint');
await c.query('DROP TABLE IF EXISTS t');
await c.query('CREATE TABLE t (id BIGINT AUTO_INCREMENT PRIMARY KEY, n VARCHAR(8))');
await c.query("INSERT INTO t (n) VALUES ('a')");

const text = (await c.query('SELECT id, n FROM t')).rows[0];                    // no params -> text protocol
const prep = (await c.query('SELECT id, n FROM t WHERE n = ?', ['a'])).rows[0]; // params  -> prepared protocol
console.log('text id type:', typeof text.id);   // both runtimes: number
console.log('prep id type:', typeof prep.id);    // Node: number   perry native: bigint
await c.close();

Expected vs actual (@perryts/mysql 0.1.4)

	text protocol	prepared protocol
Node (tsx)	number (1)	number (1)
perry native	number (1)	bigint (1n)

Expected: a consistent type across runtimes and protocols (ideally number for in-range values, matching Node — or at least the same type on both).

Impact

In an HTTP service, bigint row values fail JSON serialization, so auto-increment ids came back as null in API responses (only under the native binary, via parameterized SELECTs). Workaround: CAST(id AS CHAR) in the SELECT, or coerce bigint → Number/string in the result mapper.

Env

@perryts/mysql 0.1.4; perry 0.5.1125; MySQL 8 (local), macOS arm64.