* Fix two crashes in `rake demo_data:default`
- Demo::Generator#generate_credit_card_cycles!: the balance-adjust step created a $0 "Balance Adjust" transfer whenever a card's balance was already under its target (negative diff), which fails Transfer's opposite-amounts validation (a transfer can't have a zero amount). Only create the adjustment transfer when the diff is actually positive. - Demo::DataCleaner#destroy_everything!: ApiKey has a before_destroy guard (prevent_demo_monitoring_key_destroy!) that throws :abort to stop the demo monitoring key being revoked from the UI. That abort silently no-ops the whole Family.destroy_all cascade below it (accounts/entries/ trades all survive undestroyed), which only then surfaces downstream as a NOT NULL violation in Security.destroy_all. Delete the demo monitoring key directly (bypassing callbacks) before destroying families; safe since this class is dev/test only. Verified end-to-end: db:drop/create/schema:load, then `rake demo_data:default` followed by `SKIP_CLEAR=0 rake demo_data:default` (exercises both the generation and the clear-and-regenerate paths) complete without error.
* Reconcile below-target card balances with a charge instead of skipping
The previous fix avoided the $0 transfer crash by skipping the balance
adjustment entirely when a card's ending balance landed more than $250
under its target, but that let demo_data:default finish with Amex/Sapphire
balances far from their documented targets. A transfer can't carry a
negative payment amount, so when the diff is negative, add a direct
"Balance Reconciliation" charge on the card instead of a transfer.
Verified across 10 seeds: Sapphire now lands exactly on its $4,200 target
instead of drifting below it, with no validation errors.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
- Added `has_many :sso_audit_logs` association to `User` model with `dependent: :nullify`.
- Updated `Demo::DataCleaner` to clear SSO audit logs before destroying related data.
Co-authored-by: Josh Waldrep <joshua.waldrep5+github@gmail.com>
