feat: add kintone-upload-file tool

[Tom8810]

Why

The server could already pull attachments out of kintone with kintone-download-file, but there was no way to push a file back in. Attaching a file to a record, a space, or an app setting requires a fileKey from the File REST API, and without an upload tool that key could never be obtained—so any workflow that produced a file locally (a generated report, an edited spreadsheet, a file downloaded from another app) dead-ended at the point of attaching it.

This adds the missing half of the file round trip. The file is read from the local filesystem and streamed to kintone's temporary storage, so the file contents never pass through the conversation, and the model only handles the resulting fileKey.

What

• Add kintone-upload-file: uploads one local file to kintone's temporary storage via the File REST API (POST /k/v1/file.json) and returns its fileKey, along with the registered fileName and the fileSize in bytes. Only a single file can be uploaded per call, so the tool is meant to be called repeatedly for multiple files.
  • filePath accepts an absolute path, or a bare file name resolved against KINTONE_ATTACHMENTS_DIR (the same directory kintone-download-file writes to, so a downloaded file can be re-uploaded by name). A relative path with no KINTONE_ATTACHMENTS_DIR configured is rejected with an explicit error.
  • fileName is optional and defaults to the base name of filePath. It must not contain a path separator, and a non-ASCII name is sent as UTF-8.
  • Validates before calling the API: the path must exist and must point to a file, not a directory.
  • The description spells out that the returned fileKey is temporary-storage-scoped and is a different kind of key from the attachment fileKey returned by record retrieval (a retrieval key cannot be re-uploaded here), that uploading itself needs no specific permission, and that an unattached file is deleted after 3 days while still counting toward the domain's disk usage.
• Add uploadFile to the mock client in src/__tests__/utils.ts so file-related tools can be tested against it.
• Register the tool in src/tools/index.ts and update manifest.json, README.md, and README_en.md.
• Add tests covering the tool configuration (name, title, description, input/output schemas), absolute and KINTONE_ATTACHMENTS_DIR-relative paths, the fileName override including a non-ASCII name, and each error path (missing KINTONE_ATTACHMENTS_DIR, file not found, directory instead of file, path separator in fileName, API failure).

How to test

1. Set KINTONE_ATTACHMENTS_DIR to a directory containing a file, and configure KINTONE_BASE_URL with credentials for a test app that has an attachment field.
2. Absolute path: call kintone-upload-file with an absolute filePath and confirm a fileKey is returned and that fileName/fileSize match the file on disk.
3. Relative path: call it with just the file name and confirm it resolves against KINTONE_ATTACHMENTS_DIR. Unset KINTONE_ATTACHMENTS_DIR and confirm a relative path is rejected with a clear error.
4. Round trip: pass the returned fileKey as the value of an attachment field via kintone-add-records (or kintone-update-records) and confirm the file is attached and downloadable, then confirm kintone-download-file brings it back and that file can be uploaded again by name.
5. Rename: pass a fileName (including a non-ASCII one such as 見積書.pdf) and confirm that is the name registered in kintone, not the base name of filePath.
6. Errors: confirm a non-existent path, a directory path, and a fileName containing / each fail before any request is sent.
7. Run pnpm lint and pnpm test at the repo root.

Checklist

• Updated documentation if it is required.
• Added tests if it is required.
• Passed pnpm lint and pnpm test on the root directory.