feat: add bigint column type support and update dependencies

[ArnabChatterjee20k]

What does this PR do?

(Provide a description of what this PR does.)

Test Plan

(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work.)

Related PRs and Issues

(If this PR is related to any other PR or resolves any issue or related to any issue link all related PR and issues here.)

Have you read the Contributing Guidelines on issues?

(Write your answer here.)

[greptile-apps]

Greptile Summary

This PR adds BigInt column type support to the Tables DB UI and upgrades the @appwrite.io/console SDK dependency to pick up the new Models.ColumnBigint type and the createBigIntColumn/updateBigIntColumn API calls.

Key changes:

• New bigint.svelte column creation/editing component, modelled after integer.svelte, with submitBigInt / updateBigInt wired to the new SDK endpoints.
• bigint added to columnOptions in store.ts, the Columns type union in table store.ts, the columnTypes helper array, and the spreadsheet icon map.
• column.svelte updated so that bigint-typed row cells are edited/displayed via the existing Integer component, and the value prop type union extended with bigint and bigint[].
• string.svelte parseValue falls through bigint to the existing integer branch (using parseInt), confirmed as intentional by the author.
• Type-casting in +page.svelte now correctly includes Models.ColumnBigint in the min/max display union.

Issues found:

• The $bindable default in bigint.svelte initialises min, max, and default as number literals (0) rather than bigint literals (0n). If Models.ColumnBigint types those fields as JS bigint, this is a hidden type mismatch that the as number casts suppress at the TypeScript level.
• The PR description, test plan, and related-issues sections were left blank, making it hard to review intent or validate against an issue tracker.

Confidence Score: 4/5

Mostly safe to merge; the most critical prior concerns were addressed, but a known P1 concern around InputNumber silently losing precision for large BigInt values (> Number.MAX_SAFE_INTEGER) in the column creation/editing UI remains unresolved.

Two previously flagged P1 issues were fixed (wrong model type ColumnInteger → ColumnBigint, incorrect type cast in +page.svelte). One was confirmed intentional by the author (parseInt fall-through). The InputNumber/as number precision concern for column configuration is still present; it means creating a BigInt column with min/max constraints exceeding 2⁵³−1 will silently round values in the UI. That keeps the score at 4 rather than 5.

bigint.svelte — the InputNumber binding and 0/0n default initialisation both deserve a second look before merging.

Important Files Changed

Filename	Overview
src/routes/(console)/project-[region]-[project]/databases/database-[database]/table-[table]/columns/bigint.svelte	New BigInt column component using InputNumber with as number type casts for min/max/default; precision concerns for values beyond Number.MAX_SAFE_INTEGER remain unresolved; placeholder text says "Enter size" instead of "Enter min/max".
src/routes/(console)/project-[region]-[project]/databases/database-[database]/table-[table]/columns/+page.svelte	Type cast for bigint column correctly updated to include Models.ColumnBigint; min/max display logic already handles bigint-typed values via typeof min === 'bigint' checks.
src/routes/(console)/project-[region]-[project]/databases/database-[database]/table-[table]/columns/store.ts	Adds BigInt to columnOptions and type unions correctly; BigInt import name shadows the JavaScript global BigInt built-in, consistent with existing Boolean/String shadow pattern in the same file.
src/routes/(console)/project-[region]-[project]/databases/database-[database]/table-[table]/rows/columns/column.svelte	Adds bigint and array variants to the value type union and maps bigint rows to the existing Integer display component; Svelte 4 syntax used throughout (file not migrated to runes despite being touched).
src/routes/(console)/project-[region]-[project]/databases/database-[database]/table-[table]/rows/columns/types/string.svelte	bigint type falls through to integer branch in parseValue, using parseInt which returns a JS number; developer confirmed this is intentional behaviour.

_{Reviews (4): Last reviewed commit: "linting" | Re-trigger Greptile}

[greptile-apps]

parseInt silently loses precision for large BigInt values

When column.type === 'bigint', this code falls through to parseInt(trimmed, 10), which returns a JavaScript number. JavaScript number is a 64-bit float with only 53 bits of mantissa, meaning any integer beyond Number.MAX_SAFE_INTEGER (~9×10¹⁵) is silently corrupted.

For example:

parseInt("9007199254740993", 10)  // → 9007199254740992  (wrong, off by 1)

BigInt columns in most databases support 64-bit integers (up to ~9.2×10¹⁸), so real values in the upper range of a bigint column will be silently truncated/rounded when saved through this path.

The correct approach is to use BigInt() for the bigint case:

case 'bigint': {
    try {
        return BigInt(trimmed);
    } catch {
        return null;
    }
}
case 'integer': {
    const int = parseInt(trimmed, 10);
    return isNaN(int) ? null : int;
}

Note that adopting BigInt also requires updating the parseValue return type (number | bigint | boolean | string | null) and ensuring the JSON.stringify comparison in the reactive $effect blocks handles BigInt (since JSON.stringify(BigInt(1)) throws a TypeError).

[ArnabChatterjee20k]

Big int is just a split off from the Integer. Earlier integer only handled bigint with this, now a separate type