fix: improve wording in messaging and README files for clarity

MESSAGING.md

@@ -78,7 +78,7 @@ Chinese reference copy:
 - Short positioning summary:
   `以浏览器为主体验的加密文件传输，也支持智能体终端工作流。`
 - Agent support blurb:
-  `日常分享可直接使用浏览器；如果你需要把文件从云服务器、远程容器或自动化终端流程中传出来，也可以通过智能体使用 Xdrop。`
+  `日常分享可直接使用浏览器；如果你需要将文件从云服务器、远程容器或自动化终端流程中传出来，也可以通过智能体使用 Xdrop。`
 
 ## Messaging Priorities
 

README.md

@@ -50,7 +50,7 @@ workflows, keeping plaintext file names, contents, and keys off the server.
 
 ## Use Via Agents
 
-You can also use Xdrop through an agent by installing the bundled skill:
+You can use Xdrop through an agent by installing the bundled skill:
 
 ```bash
 bunx skills add https://github.com/xixu-me/xdrop/tree/main/skills/xdrop

README.zh.md

@@ -49,7 +49,7 @@ Xdrop 是一个开源加密文件传输应用，默认适用于浏览器，也
 
 ## 通过智能体使用
 
-你也可以把 Xdrop 作为智能体技能来用，安装存储库自带的 skill：
+你可以通过安装存储库附带的 skill 将 Xdrop 作为智能体技能来用：
 
 ```bash
 bunx skills add https://github.com/xixu-me/xdrop/tree/main/skills/xdrop
@@ -59,19 +59,19 @@ bunx skills add https://github.com/xixu-me/xdrop/tree/main/skills/xdrop
 
 - 上传本地文件或目录，并返回加密分享链接。
 - 接收完整的 Xdrop 分享链接（包含 `#k=...`）后，在本地下载并解密文件。
-- 把文件交接流程自动化，而不用每次都切换到浏览器界面操作。
+- 将文件交接流程自动化，而不用每次都切换到浏览器界面操作。
 
 适合的场景包括：
 
-- 在云服务器上让智能体把构建产物、日志或备份上传到你的 Xdrop 实例，并返回一个临时链接给你。
-- 在远程开发容器或类似 CI 的环境里，让智能体把某个目录打包后通过 Xdrop 传出来，而不是临时配置 SCP 或公开对象存储权限。
-- 在本地机器上直接把完整的 Xdrop 链接交给智能体，让它下载到指定目录并完成解密。
+- 在云服务器上让智能体将构建产物、日志或备份上传到你的 Xdrop 实例，并返回一个临时链接给你。
+- 在远程开发容器或类似 CI 的环境里，让智能体将某个目录打包后通过 Xdrop 传出来，而不是临时配置 SCP 或公开对象存储权限。
+- 在本地机器上直接将完整的 Xdrop 链接交给智能体，让它下载到指定目录并完成解密。
 
 示例指令：
 
-- `把 ./dist 上传到 https://xdrop.example.com，并给我一个 1 小时有效的 Xdrop 链接。`
-- `在这台云服务器上把 /var/log/myapp 通过 Xdrop 发出来，我要在本地排查。`
-- `把这个 Xdrop 链接下载到 ~/downloads，并保留原始目录结构。`
+- `将 ./dist 上传到 https://xdrop.example.com，并给我一个 1 小时有效的 Xdrop 链接。`
+- `在这台云服务器上将 /var/log/myapp 通过 Xdrop 发出来，我要在本地排查。`
+- `将这个 Xdrop 链接下载到 ~/downloads，并保留原始目录结构。`
 
 ## 工作原理
 
@@ -86,9 +86,9 @@ Xdrop 不会让服务端接触到明文文件名、路径、内容或解密密
 
 关键技术细节：
 
-- **加密模型：** 浏览器会为传输根密钥和分享链接密钥各生成一个 32 字节随机密钥。随后使用 HKDF-SHA-256 派生出清单和每个文件各自的 AES-256-GCM 密钥，并在分块加密时把 `transferId`、`fileId`、`chunkIndex`、大小和协议版本作为认证附加数据绑定进去。
+- **加密模型：** 浏览器会为传输根密钥和分享链接密钥各生成一个 32 字节随机密钥。随后使用 HKDF-SHA-256 派生出清单和每个文件各自的 AES-256-GCM 密钥，并在分块加密时将 `transferId`、`fileId`、`chunkIndex`、大小和协议版本作为认证附加数据绑定进去。
 - **分块上传：** 服务端会向浏览器声明分块大小、文件数限制和传输总大小限制。当前存储库默认使用 8 MiB 分块，最多 100 个文件，加密后的传输总大小上限为 256 MiB。
-- **断点续传：** 当浏览器支持 OPFS 时，Xdrop 会把源文件持久化到本地；如果不可用，则在回退存储限制范围内使用基于 IndexedDB 的 Blob 存储。恢复上传时，浏览器会先询问 API 哪些分块已存在，因此即使刷新页面或重新打开浏览器，也只会补传缺失的部分。
+- **断点续传：** 当浏览器支持 OPFS 时，Xdrop 会将源文件持久化到本地；如果不可用，则在回退存储限制范围内使用基于 IndexedDB 的 Blob 存储。恢复上传时，浏览器会先询问 API 哪些分块已存在，因此即使刷新页面或重新打开浏览器，也只会补传缺失的部分。
 - **发送方控制：** 管理令牌只会在创建时返回一次，服务端保存的是它的 SHA-256 哈希。开启隐私模式后，发送方本地控制信息可在上传完成后被清除。
 - **后端职责：** API 从不解密载荷。它负责校验传输状态、限制速率、签发预签名 URL、存储元数据，并清理已过期或已删除的对象。
 
@@ -135,7 +135,7 @@ flowchart LR
 
 ### 推荐的生产拓扑
 
-面向公网部署时，建议把 Xdrop 放在 Caddy 或 nginx 之类的反向代理后面：
+面向公网部署时，建议将 Xdrop 放在 Caddy 或 nginx 之类的反向代理后面：
 
 - 反向代理为你的公网域名终止 HTTPS。
 - `xdrop` 容器只监听回环地址上的主机端口，例如 `127.0.0.1:8080`。
@@ -165,13 +165,13 @@ curl -fsSL -o .env.example \
   https://github.com/xixu-me/xdrop/raw/refs/heads/main/.env.example
 ```
 
-如果你打算自行构建镜像，请改为克隆存储库，以便 Docker 拿到完整的构建上下文。通常更推荐在 CI 或另一台机器上完成构建，再把最终镜像拉到服务器上部署。
+如果你打算自行构建镜像，请改为克隆存储库，以便 Docker 拿到完整的构建上下文。通常更推荐在 CI 或另一台机器上完成构建，再将最终镜像拉到服务器上部署。
 
 ### 第二步：检查配置
 
 在服务器上安装 Docker 和 Docker Compose，然后检查 `docker-compose.yml` 中 `xdrop` 服务的环境变量。
 
-至少需要把这些值替换成真实部署所用配置：
+至少需要将这些值替换成真实部署所用配置：
 
 - `S3_PUBLIC_ENDPOINT`
 - `ALLOWED_ORIGINS`
@@ -193,7 +193,7 @@ services:
       ALLOWED_ORIGINS: https://xdrop.example.com
 ```
 
-请把 `.env.example` 视为支持配置项的参考清单。仅修改 `.env.example` 不会影响运行中的栈，因为存储库附带的 Compose 文件使用的是内联环境变量。
+请将 `.env.example` 视为支持配置项的参考清单。仅修改 `.env.example` 不会影响运行中的栈，因为存储库附带的 Compose 文件使用的是内联环境变量。
 
 ### 第三步：使用已发布镜像
 
@@ -239,9 +239,9 @@ services:
         VITE_API_BASE_URL: /api/v1
 ```
 
-在低内存服务器上直接构建可能会很慢甚至失败。这种情况下，建议在其他机器完成构建，把镜像推送到存储库后，再通过 `XDROP_IMAGE` 部署。
+在低内存服务器上直接构建可能会很慢甚至失败。这种情况下，建议在其他机器完成构建，将镜像推送到存储库后，再通过 `XDROP_IMAGE` 部署。
 
-### 第六步：把 Xdrop 放到反向代理后面
+### 第六步：将 Xdrop 放到反向代理后面
 
 `Caddyfile` 示例：