fix(perf): warm NFS sqlite with 64MB cache + transactions indexes + parallel trend (rant 2026-08-25T12:02:13)

[argszero]

Summary

Fix the slow transactions page caused by the dev database living on NFS (Aliyun NAS). Browser-measured /api/transactions 1.7s, page refresh ~5s.

Rant: 2026-08-25T12:02:13 — 交易页慢（dev 库在 NFS）：调大 SQLite 页缓存 + 建索引 + 前端并行拉 trend

Root cause (verified on dev)

1. Cache layer: SQLite default cache_size is 2MB < DB 2.8MB; db.rs open() set no PRAGMAs → every query re-reads pages from the remote NFS volume (cold read ~0.93s/COUNT vs 26ms on local SSD).
2. Data layer: transactions had zero indexes → summary/COUNT/list full-table scans + 3 LEFT JOINs (dev: 23079 rows).
3. Frontend: loadTransactions awaited the list before fetching trend → one extra ~0.9s serial hop per page load.

Verified fix on NAS (3 consecutive COUNTs): default cache 2.39s → cache_size=64MB 0.80s → 64MB+mmap 0.40s (fully hot after first read).

Changes

• src/db.rs:
  • open() now sets PRAGMA cache_size=-65536 (64MB) and PRAGMA mmap_size=67108864 — whole DB resident in process memory, NFS read once.
  • v12 migration (schema 10 → 12): creates 4 indexes on transactions: (user_id), (user_id, id DESC), (user_id, time), (user_id, type).
  • New test transactions_perf_indexes_created_on_migrate asserts all 4 indexes exist.
• ui/js/app.js: loadTransactions fetches list + trend with Promise.all — failures are independent (list failure → empty state + retry; trend failure → trend=null), behavior preserved.
• ui/index.html: cache-bust 20260825-3 → 20260825-4.

Constraints honored

• No WAL (SQLite officially unsupported on network filesystems — corruption risk).
• DB stays on NAS (deployment hard constraint).

Tests

• cargo test — 148/148 pass (147 + 1 new)
• cargo fmt --check clean
• node --check ui/js/app.js OK