Chore/history UI improvements

[ktarun1419]

• Added a one-time Gold history projection after Bronze/Silver backfill completes; subsequent updates are processed incrementally.
• Added a per-account readiness flag to safely reroute History APIs from legacy data to Gold history.
• Added PostgreSQL leader election for Apalis jobs so only one application instance runs background workers, with safe leadership handover.
• Fixed delayed exchange fulfillment and recomputation to maintain correct historical balances.
• Ensured history rows, counts, and prior balances consistently use the same data source.
• Fixed token decimal handling and confidential-history filtering.

[frol-ai]

Reviewed the background-jobs leadership part (jobs/leadership.rs, jobs/mod.rs, the background_job_leader migration, render.yaml) — it's directly relevant to the DB-connection/reliability incident we've been chasing. Overall this is a well-built, correct approach; comments below focus on that infra and its overlap with the other in-flight fixes for the same incident.

The leadership design is solid ✅

• Using pg_try_advisory_lock as the actual mutex is the right primitive — it's session-scoped, so if the leader's connection dies (exactly our Postgres-crash case) the lock auto-releases and a follower can take over. No split-brain.
• Generation fencing + rows_affected() == 1 on the heartbeat correctly detects "I lost leadership" and steps down.
• Graceful drain (stop_runtime, 45s) + render.yaml maxShutdownDelaySeconds: 90 addresses the deploy-overlap connection storm nicely.
• On HeartbeatFailed it discard()s (close-on-drop) rather than trying to release on a dead connection — correct.
• Compatible with the pool-lifecycle hardening in #1155: the advisory-lock connection is held checked-out for the leader's lifetime, so it's exempt from idle_timeout/max_lifetime reaping — no premature lock loss. Worth a one-line comment in the code noting that this connection is intentionally never returned to the pool.

Coordinate with the other incident PRs (same files/incident)

This is one of several parallel fixes for the 2026-07-20 stall; they're complementary but touch the same code:

• #1159 (cron-worker restart backoff) is still needed inside the leader's runtime. Leadership only stops the cron hot-loop after the ~5–10s heartbeat-failure detection window; during that window the CronStream→store pipe error makes the Monitor rebuild cron workers with zero delay, spinning CPU and hammering the DB — which is what cascaded the original outage. Landing #1159 makes that window calm.
• #1154 (liveness monitor) — you've kept run_liveness_monitor inside the runtime (good). But with leadership's cancellable runtime + heartbeat failover, its std::process::exit(1) is now a heavier hammer than needed; consider having it signal the leadership loop to step down/re-elect instead of killing the process.
• #1155 pool hardening and #1157 price-sync query cache reduce connection footprint and the heavy query that pressures the DB — orthogonal, keep both.

Packaging concern ⚠️

A major infra change (867-line leadership module + a jobs/mod.rs rewrite + a migration + render.yaml + a new pool connection) is bundled here with "history UI improvements" and unrelated changes (routes/balance_changes.rs +228, token_prices/*, gold/projector.rs, …). That makes it hard to review safely and risky to land/rollback as one unit. Strongly suggest splitting the background-jobs leadership into its own PR so it can be reviewed and merged on its own merits — especially since it will conflict with the merged/in-flight incident PRs and wants a careful rebase.

Happy to rebase my pool/backoff/cache PRs on top of the leadership change (or vice-versa) once we decide the ordering.