# 采购提交事务负载下超时返回500

## Goal

消除采购提交（及同结构的报销新建/提交）在负载下超过 Prisma 交互事务默认 5000ms 上限而返回 500（P2028）的问题。

## Background / Evidence（2026-09-26/27）

- 09-26 负载复现（采购 ×6–8 + permission-direct-access ×6–8，4 worker，2 核主机）每轮出现 1–2 次 `purchase submit failed: 500`，服务端为 `P2028 Transaction API error ... timeout 5000 ms, 5352 ms passed`，位于 `server/src/routes/purchaseRequests.js` 提交事务内的 `workflowTask.create`。正式门禁 6 轮未出现。
- 生产 `b1d25d3c` 与当前代码同写法（默认超时），非近期回归。
- 09-27 事务内分段计时（16 次提交全部成功）：锁定单据中位 41/最大 290ms；编号前校验与预检 466/1659ms；编号分配含锁等待 101/535ms；编号后至提交 317/2194ms；**事务总时长中位 843ms、最大 3506ms**。无单一瓶颈：编号行锁等待最多 0.5s，主要是约 20 条顺序查询在负载下整体变慢，贴近 5s 上限。
- 报销新建（`POST /reimbursements`）与提交（`/reimbursements/:id/submit`）同样在默认超时事务内分配编号、执行多步写入，属同一风险。

## Scope

- 采购提交、报销新建、报销提交三处交互事务显式使用项目既有写法 `{ maxWait: 5000, timeout: 10000 }`（付款批次、回执 OCR 等已采用）。
- 不改事务内容、顺序、锁、编号或业务语义。

## Out of Scope

缩短编号行持锁时间的重排、其他路由事务的统一治理、部署。

## Acceptance Criteria

- [ ] 三处事务传入 `{ maxWait: 5000, timeout: 10000 }`，采购与报销提交各有回归断言（去掉修复即失败）。
- [ ] 后端全量单测通过。
- [ ] 负载复现不再出现采购提交 P2028。

## Test Plan

- `server/tests/unit/routes/purchase.submit-budget-precheck.test.js`：新增断言提交事务选项；已验证去掉修复时该用例失败。
- `server/tests/unit/routes/reimbursements.expense-standards.test.js`：在既有成功提交用例中断言事务选项。
- 后端全量 vitest；负载复现脚本（见 09-26-approve-success-state-unchanged/research/repro.sh）。