Fix Quick Capture opening-balance parity

[AFR0011]

Summary

Fixes a post-release correctness defect where server-side Quick Capture balance validation treated opening checkpoints like reconciliations.

The canonical local ledger already defines opening checkpoints as baseline snapshots: any activity created after the opening checkpoint must be replayed, even when its business date is backdated before or onto the opening date. The deployed taptrack_calculated_balance RPC had drifted from that rule and could raise unresolved same-day ordering errors or omit backdated activity.

Changes

• update taptrack_calculated_balance in a new Supabase migration to retrieve checkpoint kind
• for opening checkpoints, replay transactions/conversions created after the checkpoint regardless of business date
• keep ambiguity detection limited to reconciliation checkpoints
• preserve the historical RPC name for compatibility
• add transaction regression coverage for activity entered later but dated before/on an opening checkpoint
• document the narrow post-release correctness fix

Safety

• no existing finance records are rewritten
• no checkpoint or transaction timestamps are patched
• reconciliation semantics remain unchanged
• migration only replaces the existing balance-calculation function

Verification

Ravel CI should run the repository verification ladder on this PR. Production Supabase migration is intentionally not applied until the code review/CI gate passes.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
ravel	Ready	Preview	Sep 17, 2026 8:03pm UTC