feat: 补齐报销付款待办交接（09-11-reimbursement-payment-handoffs）

.trellis/spec/hyb-oa/backend-fastify-prisma.md

@@ -23,6 +23,40 @@ QA script patterns over new abstractions.
 - `cd server && ./scripts/regression-workflow-actions.sh`
 - `cd server && ./scripts/regression-all.sh`
 
+## Scenario: Read-only Reimbursement/Payment Handoffs
+
+### 1. Scope / Trigger
+
+The portal must expose business work between reimbursement return, approval, batch creation, independent review and payment recording, without a new todo store or notification dependency.
+
+### 2. Signatures
+
+`loadReimbursementPaymentHandoffs(fastify, employee)` supplies `businessHandoffs: { total, items }` on the authenticated `GET /portal/home` route. Each item has `key, kind, reference, title, nextStep, ownerLabel, href, mobileHref`; kind is one of `reimbursement_edit | reimbursement_batch | payment_review | payment_execute`.
+
+### 3. Contracts
+
+Use a RepeatableRead, READ ONLY transaction (5s acquisition, 10s execution limit). Select necessary identity/reference/stage/department facts, never bank snapshots or amounts. Stable stage/object keys are unique; total equals all returned items, with no silent eight-row cutoff. Mutations retain their own authoritative gates. No schema, new environment setting, persistent todo, decryption or notification send is introduced.
+
+### 4. Validation & Error Matrix
+
+- Returned work requires participant + submit/read rights and the latest workflow's final return/reject fact; new, withdrawn, paid and deleted drafts are excluded.
+- Unbatched approved sources require manage permission, exclude deleted/paid and non-cancelled reservations. Missing bank data remains work, not proof of readiness.
+- Review requires manager/ceo + review permission, a different maker, draft/unreviewed status and pending items. Reviewed/failed processing requires manage.
+- Payment work requires both global and source-department payment gates. Missing/deleted batch sources do not yield actionable handoffs.
+- Query failure follows the existing API error boundary and frontend retry state; never convert it into a successful zero-items response.
+
+### 5. Good / Base / Bad Cases
+
+Good: review moves work from the non-maker reviewer to finance. Base: genuinely no qualifying work returns zero items. Bad: a historical return followed by withdrawal, self-review, or a hidden source must not produce an action.
+
+### 6. Tests Required
+
+Service/route tests cover permissions, department gates, latest-history selection, deleted sources, no read side effects and stable counts. Real isolated return/resubmit/create/review/receipt/paid transitions must prove work appears and disappears. PC/mobile tests cover refresh, errors, more than eight items and no double-counting of legacy finance aggregates; source-only or mock-only checks are insufficient for final acceptance.
+
+### 7. Wrong vs Correct
+
+Wrong: treat a notice count or pending-batch aggregate as the complete finance worklist. Correct: derive four business handoffs from current facts; when the new DTO is present, omit the old pending/failed aggregates from action counts while preserving independent risk reminders. Notification outages do not erase business work.
+
 ## Scenario: Business Error Reasons And Payment Creation Readiness
 
 ### 1. Scope / Trigger