Payout exception observations

Migration 20261011001300_payout_exception_observations.sql adds private, read-only list/detail observations. Mount payoutExceptionObservationsRoutes at /payout-exceptions within the authenticated admin router and render finance/PayoutExceptionPanel on the finance investigation screen for users with global canViewFinanceReports. The database independently checks current active staff and permission template under shared locks; browser RPC calls and campus-scoped grants are denied.

The list counts all exceptions and returns the latest 100. Detail accepts an exact payout UUID, including records that currently meet no exception criteria. Every response includes an observation timestamp. Missing canonical tables or columns fail the observation instead of reporting zero; absent debit/restoration entries remain null and are labelled missing evidence.

Sources are payout_requests, migration011 payout_transfer_intents, and exact ledger transaction identities PAYOUT-{payout UUID} / PAYOUT-REV-{payout UUID}. The latter is a wallet restoration after rejection or transfer failure, not an unrelated order refund. Normal pending payouts with matching pending debits are excluded. Criteria cover uncertain or expired dispatches on nonterminal payouts, processing over an explicit 24-hour local threshold, dispatched intent/payout reference conflicts, debit amount/account/type/status contradictions, and missing or contradictory restoration evidence.

Provider outcome is always not_verified: the source schema contains no independently verified provider final-state receipt. submitted records acceptance of initialization and does not establish successful bank delivery. Canonical processed/failed status is displayed as local evidence. No bank snapshot, account number, recipient code, claim token, internal note or unrestricted provider payload is exposed. No retry, dispatch, wallet adjustment or payout mutation is offered.

Verification: scripts/db-payout-exception-checks.mjs exercises SQL with the actual authoritative staff predicate and representative source schemas. Backend receipt tests and frontend unavailable/empty/revocation tests run separately. This fixture verification does not establish compatibility with the full hosted baseline; migration rollout remains separately controlled.