feat: accept BigInt values in intColumn()

[PedroHenrique0713]

Closes #58.

Picking this up since it has been open since February and @saibotsivad, who offered to send a PR, has not had the chance. Happy to step aside if they would rather land it themselves.

Implements exactly the signature @glasstiger asked for in the issue thread:

intColumn(name: string, value: number | bigint): Sender

number is kept for backwards compatibility.

Why

QuestDB's LONG is a 64-bit signed integer. JavaScript's number is a double, so anything above Number.MAX_SAFE_INTEGER (9007199254740991) is already rounded by the time it reaches intColumn() — the loss happens at the call site and nothing downstream can detect it. There was no way to write a full-range LONG from this client.

What changed

• src/buffer/base.ts — intColumn() takes number | bigint, validated the same way timestampColumn() already validates its own number | bigint parameter: typeof value !== "bigint" && !Number.isInteger(value).
• src/buffer/index.ts and src/sender.ts — signatures and JSDoc.

The wire format is unchanged: value.toString() renders a BigInt without the trailing n, so the ILP line is identical for a value expressible both ways.

Tests

Two new cases in test/sender.buffer.test.ts:

• BigInt values, positive and negative, produce the expected ILP line
• 9223372036854775807n (2^63-1, the largest LONG) survives the round trip. As a number it rounds to 9223372036854775808, which is out of range for the column

One existing test is updated: the non-integer error message now mentions BigInt, matching the wording timestampColumn() uses.

vitest passes locally, eslint and prettier --check are clean. tsc --noEmit reports one pre-existing error about conflicting undici FormData types, unchanged by this branch (same count on a clean checkout).