fix: preserve int64 file IDs

[victor0602]

What changed

• Stop coercing file IDs through JavaScript Number in CLI and FileSDK deletion paths.
• Normalize positive int64 IDs as decimal strings and reject invalid or unsafe numeric inputs locally.
• Support string, safe integer number, and bigint inputs in FileSDK.
• Add coverage for IDs above Number.MAX_SAFE_INTEGER and the int64 boundary.

Why

JavaScript Number cannot precisely represent the complete int64 range documented by the file deletion API.

Impact

Large file IDs are sent without precision loss, while existing safe numeric callers remain supported.

Checks

• bun test — 453 passed
• bun run typecheck
• bun run lint — no errors; one pre-existing test warning
• git diff --check

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[NianJiuZst]

I do not recommend merging this revision until the File Delete wire contract is resolved.

[P2] Align the payload with the documented File Delete contract before changing the SDK type. The current official schema declares file_id as integer<int64> and purpose as required, while this sends only a decimal string; the PR also changes FileDeleteResponse.file_id to string. The examples and schema are inconsistent enough that self-authored mocks cannot prove compatibility. Please either send the documented shape (including purpose) or add provider-backed evidence for string IDs and document the supported purpose behavior before merging.

Official contract: https://platform.minimax.io/docs/api-reference/file-management-delete

Local verification: typecheck, lint (one pre-existing warning), build, 11 focused tests, and the full suite (453/453) passed. The tests currently assert the implementation's own request/response shape rather than the documented provider schema.