fix(upload): 优化上传命令参数处理流程解决上传失败问题#29
问题: 路径拼接存在路径遍历风险：moduleName 和 toolName 直接拼入文件路径，未校验是否包含 .. 等目录遍历字符。虽然这两个参数来源于 resolveShortcut 或 CLI 输入，但 loadToolFunction 作为独立函数没有对输入做任何校验。
建议: 对 moduleName 和 toolName 做基本校验，拒绝包含路径分隔符或 .. 的输入：
if (moduleName.includes('/') || moduleName.includes('..') || toolName.includes('/') || toolName.includes('..')) {
console.error('无效的模块名或工具名');
process.exit(1);
}
问题: executeUpload 中 loadToolFunction(shortcut.module, shortcut.tool) 调用发生在 opts.file 校验之前。当 --file 未提供时（虽然 requiredOption 理论上保证了，但 handleUpload 内部仍然检查了 !filePath），会先执行不必要的模块加载，包括 fs.existsSync 和 require。
建议: 可以考虑将 loadToolFunction 调用移到 handleUpload 内部文件校验通过之后，或者在 executeUpload 中提前校验 opts.file，避免无文件时触发不必要的模块加载。这不是严重问题，但可以改善资源使用。
问题: apiFirstArg 使用 any 类型绕过了 UploadApiFunction 签名中第一个参数 params: UploadPathParams 的类型约束。当 isIssueUpload 为 false 时，传入的是 pathParams.repo（一个 string），与 UploadApiFunction 定义的 params: UploadPathParams 类型不匹配，但 any 掩盖了这个差异。
建议: PR API 和 Issue API 的函数签名不同，不应共用 UploadApiFunction 类型。考虑：
- 定义两种 API 函数类型分别描述 Issue 和 PR 的签名
- 或将
toolFunction类型改为更宽泛的联合类型
type IssueUploadFn = (params: UploadPathParams, body: IssueUploadBody) => Promise<UploadApiResponse>;
type PullUploadFn = (repo: string, body: PullUploadBody) => Promise<UploadApiResponse>;
重构上传命令执行逻辑，拆分独立分支并修复 API 调用签名