fix(bjb): report and verify recorded bank allocations BJB reports joined payment history to bill totals, so a shortfall could appear repeatedly at the assessed amount. Report each supported positive bank payment allocation using its stored amount across the list, export, counts, KPI and daily summary. Keep multiple payments and partial payments before settlement; exclude transfers, imports, inquiries and bookkeeping from claimed bank cash. Use validated bank dates with a labelled posting-date fallback. Keep principal, penalty and excess separate and nullable when the history cannot establish a split. Verification checks the exact selected receipt and displayed evidence under row locks, preserves money and settlement history, and enforces BJB/Admin at exposed server entry points. ## Validation - All 108 generated-data tests pass with the existing locked dependency set: 75 functional SQL/action/client tests, 7 actual TSX callback/row-key/export tests and 26 read-attribution regressions. No tests were skipped. - With 500 genuine allocations and 12,000 unrelated history rows, a five-row default page performs five history calculations; counts and the daily summary perform none. These PGlite PostgreSQL 18.3 measurements do not establish production latency or native PostgreSQL 17 concurrency. - All four UI policy scanners pass. Full React Doctor is complete with zero diagnostics and no incomplete checks. Drizzle query policy reports zero violations and zero exceptions. - Existing BJB CI runs the six allocation suites; the attribution suite remains in its existing workflow step. Canonical pinned-pnpm CI is still required before merge. - Local checks used existing cached dependencies and blocked network access. No local application build, development server or package installation ran. Callback tests use explicit inert boundaries and do not claim a browser mount. ## Rollout No schema migration is required. Rows and counts represent recorded payment allocations, so a bank reference shared across payment codes remains separate. Unsupported or unquantified legacy evidence is not presented as observed cash, and verification never fabricates a payment. Component splits may be unknown while the stored received amount remains visible. Refresh open verification pages when a stale-record response requires it. Automatic deployment and migration settings remain unchanged. Closes #1915 CI mitigation: add `--no-wasm-code-gc` to the government-filing PGlite command after its native V8/Wasm allocator crash; canonical CI must verify the change. Related: #1922. This is an isolated candidate; merge one reviewed implementation. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> <!-- coderabbit-ai-generated:v1 --> ## Summary by CodeRabbit * **New Features** * BJB payment listings, summaries, and exports now reflect receipt allocations, including payment time, allocation amounts, and allocation basis. * Verification details show receipt evidence and bank references; ambiguous allocation values are marked as unconfirmed. * Verification now requires selecting an eligible existing payment when needed and reports when a receipt is unavailable or its details have changed. * BJB reporting and verification are restricted to authorized access. * **Updates** * Summary and KPI labels now refer to allocations, with “Mix BJB” renamed “Kanal Lain.” * Verification exports use receipt and allocation details, including times shown in WIB. <!-- end of auto-generated comment: release notes by coderabbit.ai -->