toml-node: toml.parse()における、長さの制限のない整数リテラルが原因による、制御不能なリソース消費（CPU DoS）

### 概要
`toml.parse()`は、整数リテラル（16進数、8進数、2進数、および10進数）を、桁数の長さを事前に制限せずに`BigInt`に変換します。非常に長い数値文字列から`BigInt(string)`を構築すると、実行時間が線形よりも大きくなるため、1つの長い整数リテラルを含む、小さくても正しく記述されたTOMLドキュメントが、Node.jsプロセスのイベントループを数秒間100%のCPU使用率で占有し、攻撃者が提供したTOMLや、サードパーティ製のTOMLを解析するアプリケーションに対して、サービス拒否を引き起こす可能性があります。認証や複雑な操作は必要ありません。

### 詳細
`lib/parser.js`において、整数ノードを構築する文法アクションは、一致した数字のテキストに対して、長さの上限なしに直接`BigInt()`を呼び出します。

- `lib/parser.js:326` — 16進数: `BigInt('0x' + stripUnderscores(digits))`
- `lib/parser.js:327` — 8進数: `BigInt('0o' + stripUnderscores(digits))`
- `lib/parser.js:328` — 2進数: `BigInt('0b' + stripUnderscores(digits))`
- `lib/parser.js:329` — 10進数: `BigInt(stripUnderscores(text))`

パーサーは、深くネストされた配列/インラインテーブルによるスタックオーバーフローを防ぐために、ネストの深さの制限（`MAX_DEPTH`、デフォルト値は500、`lib/parser.js:4343`）を設けています（GHSA-82x6-q7mm-w9cf参照）。ただし、この制限は構造的なネストのみを制限し、単一のスカラートークンの長さを制限するものではありません。

`lib/compiler.js`における、その後の64ビット範囲のチェック（`reduceInteger`、143〜150行目、`INT64_MIN` / `INT64_MAX`を3〜4行目で定義）は、高価な`BigInt()`変換が完了した**後**に行われます。したがって、このチェックは、このコストに対する保護を提供しません。値が範囲外であると判断される前に、CPU時間はすでに消費されています。

### 実証コード

```js
const toml = require('toml');

const N = 5_000_000; // 約5MBのリクエストボディ
const doc = 'x = 0x' + 'f'.repeat(N);
```

```
const start = Date.now();
try {
toml.parse(doc); // 最終的には "64ビット符号付き整数範囲外" というエラーが発生する可能性があります。
// しかし、それはコストのかかる変換処理が完了した後で初めてです。
} catch (e) {}

console.log('経過時間:', Date.now() - start, 'ms');
```

**測定結果:**

| 桁数 (16進数) | 推定ペイロードサイズ | 処理時間 |
|---|---|---|
| 200,000 | 約200 KB | 141 ms |
| 400,000 | 約400 KB | 276 ms |
| 800,000 | 約800 KB | 685 ms |
| 1,600,000 | 約1.6 MB | 1,761 ms |
| 5,000,000 | 約5 MB | 6,061 ms |

増加は明らかに線形以上です。同様の動作は、単純な10進数のリテラル（3,000,000個の `'9'` 桁 → 約6.3秒）でも確認されます。

### 影響
`toml.parse()` を、信頼できない入力やサードパーティからの入力に対して呼び出すアプリケーションは、脆弱にさらされます。具体的には、設定ファイルのアップロードエンドポイント、CI/CDツールがユーザーから提供された `.toml` ファイルを処理する箇所、パッケージマネージャー、リンター、エディタ/言語サーバーなどです。

変換処理中に、イベントループが完全にブロックされます。一般的なシングルスレッドのNode.jsサーバーでは、これにより**すべての**同時リクエスト処理が停止します。悪意のあるペイロードを含む単一の約5 MBのリクエストだけでも、数秒間のCPUリソースの完全な停止を引き起こす可能性があります。

**推奨される対策:** `BigInt()` を呼び出す前に、適切な長さ以上の数字の並びを拒否します。これは、既存の `maxDepth` オプションと同様のものです。64ビット符号付き整数には、最大で20桁の10進数または16桁の16進数が必要です。したがって、それよりも大幅に長い数字の並びは、既存の範囲チェックで確実に失敗し、代わりに、完全な `BigInt` 変換にかかるコストを避けるために、安価な `.length` 比較で拒否できます。

影響を受けるパッケージ:
- npm (JavaScript) toml: 影響を受けるバージョンは 5.0.0 以下、5.0.1 で修正済み。
```