修复手工开票下载与错误提示

docs/project/frontend-backend/backend-to-frontend-notes.md

@@ -399,6 +399,8 @@ M009 后端 CP2 已实现：页面可不依赖订单或任务，用户手工填
 - 正式业务生成接口为 `POST /api/reservation/invoices/manual-generations`，需要 Bearer token、酒店访问权和 `RESERVATION_INVOICE_GENERATE` 权限。
 - 第一版后端只支持 `source_type=MANUAL`，`task_id` / `order_id` 可以为空；传入时后端会反查对象所属酒店；如果两者同时传入，任务必须属于该订单，否则返回 `RESERVATION_INVOICE_CONTEXT_MISMATCH`。
 - 第一版后端最多支持 10 条费用明细；超过 10 条会返回 `RESERVATION_INVOICE_VALIDATION_FAILED`。
+- `pdf_url` 前端会优先用 `fetch + Blob` 下载；如果 OSS CORS 不允许浏览器读取文件，则只能退回打开 PDF 页面。若测试环境或正式环境需要稳定下载按钮，建议后端后续提供带 `Content-Disposition` 的下载代理或签名下载 URL。
+- 错误响应里的 `error_code` 用于普通用户主提示；`message` / `details[]` 前端仅折叠为技术详情，避免把字段路径、模板异常等内部信息直接铺到主提示区。
 - 第一版暂未提供 Invoice 历史列表、详情查询、任务 / 订单预填接口和客户联系人目录查询接口；前端客户 / 联系人候选可先按 M009 文档中的种子数据实现。
 - 前端不得直接调用 `POST /api/system/document-conversions/excel-to-pdf` 来完成业务开票；该接口是 M008 调试 / 后台工具能力，受 access key 控制，不具备业务开票审计和权限边界。
 

docs/project/frontend-backend/frontend-to-backend-api-requests.md

@@ -1013,10 +1013,12 @@ POST /api/reservation/invoices/manual-generations
 - `recipient.company_code` 和 `recipient.contact_id` 用于表达目录选择结果；`company`、`attention`、`address`、`telephone`、`email` 是最终用于生成 PDF 的文本值，Manual 覆盖时也必须提交。
 - 后端需要重新计算金额、VAT 和合计；前端计算只做预览。
 - 后端需要返回可预览 / 下载的 PDF URL。
+- `pdf_url` 第一版可作为预览地址；前端会优先用浏览器 `fetch + Blob` 触发下载，避免跨域场景下 `<a download>` 失效。如果 OSS CORS 不允许浏览器读取文件，前端会退回打开 PDF 页面。后续如要求稳定下载体验，建议后端提供带 `Content-Disposition` 的受控下载代理或签名下载 URL。
 - 该接口应走 Bearer 登录、酒店访问权和 `RESERVATION_INVOICE_GENERATE` 权限，不走 M008 调试上传 access key。
 - 第一版最多支持 10 条 `charges[]`；超过 10 条会返回 `RESERVATION_INVOICE_VALIDATION_FAILED`。
 - 第一版只支持 `template_code=PROFORMA_INVOICE_V1`，模板文件由后端受控维护。
 - 第一版已写入 `workflow_reservation_invoice_generation` 生成记录和业务审计，但暂不提供前端查询历史列表 / 详情接口。
+- 错误响应中的 `error_code` 用于前端主错误文案映射；`message` / `details[]` 只作为折叠技术详情展示，不直接铺给普通用户。
 
 ## 13. 已确认后置接口