refactor(wallet): move chat gifts and rain onto bonus grants

[zaxovaiko]

Summary

Stacked on #190. Removes wallet's fungible bonus_credit rollover model and moves chat gifts and rain onto bonus grants. Net negative diff. BF-592.

Why

Two bonus models were running side by side on the same bet. Wallet's credits the money into wallet_balance and subtracts a proportional un-rolled share at withdrawal time; the grant engine keeps bonus funds out of the balance entirely and converts them once they are wagered.

That is two answers to "what is locked", two rollover engines advancing on the same stake, and a debit() with two bonus branches. The branches were genuinely disjoint - one reads wallet_balance, the other the grant - but "genuinely disjoint, trust me" is exactly the shape of comment that precedes someone consolidating them into a bug.

Gifted money is a bonus. A gift or a rain drop now creates a grant rather than crediting the real balance. The terms it is granted under live in the bonus module rather than being passed in by the wallet: the wallet's job is to report that a player was given money, and what that obliges them to do with it belongs to the module that owns bonus policy. A grant with no offer behind it scores against a seeded default weight profile - reference data for the same reason the IAM roles are, since a gift that cannot resolve a profile would be refused and an operator should not have to remember to create one.

This is a visible behaviour change and worth saying plainly. Gift and rain money used to be spendable as real balance with a share locked at withdrawal. It is now bonus balance that has to be wagered before it converts. Same product rule, expressed in the model the specification asks for.

Withdrawal and swap lose their locked-share subtraction, and nothing replaces it. debitWithdrawableBalance existed only because the old model mixed the two kinds of money in one row. Grant money never enters wallet_balance, so everything that row holds is the player's own and amount >= requested is a complete guard again. There is a test that gifts a player 500, then withdraws their entire 100 deposit and expects it to succeed.

promo.bonus.completed replaces wallet.bonus_rollover.completed as the player-facing notification, emitted after the transaction that moved the money commits.

What is removed

Tables wallet_bonus_credit and wallet_bonus_rollover_config with their enums; the bonus-rollover-config IAM resource; three wallet.bonus_credit* audit actions; the wallet.bonus_rollover.completed event; the player rollover-status route and the admin config route pair; createBonusCredit, applyBonusRolloverProgress, resolveRolloverMultiplier, debitWithdrawableBalance, readLockedBonusAmount, WalletDebitOutcome.completedBonusCredits; the rollover seed; and four test files covering the deleted model.

Alternatives considered

Keeping both and deprecating later. The interim state is the problem, not the migration: every bet would advance two rollover engines, and a reviewer would have to hold both in their head to judge the money path.

Migrating existing bonus_credit rows onto grants. Those rows hold money that is already inside wallet_balance, so carrying them across is a money-moving migration on live balances - debit each holder by their locked share and re-materialise it as bonus. Nothing here is in production, so the rows are dropped instead.

Passing the gift terms in from the wallet, via platform config. Tried and reverted. It put a bonus policy decision in the module that has no business making one, and threaded configuration through a seam that exists to move money.

Risks

Dropping wallet_bonus_credit releases every outstanding locked share. The model being removed credited gift money into wallet_balance and held the un-wagered part back only at withdrawal time, so any active wallet_bonus_credit row is money that is already in the balance and is only locked by the code this PR deletes. The migration drops the table with no data migration, which means every unmet rollover requirement is cancelled at deploy - no ledger entry, no audit row, no event.

That is a deliberate call, not an oversight: nothing here is in production and data loss on this table is accepted. If that ever stops being true, the fix is a data migration ordered before the drop that either moves each active row's unmet share onto a promo_grant or forfeits it with an audit record.

A gift now refuses when no bonus engine is bound. Previously the requirement was attached unconditionally; now it lives in the promo module, so a consumer whose extension list omits bonus gets an error on gift and rain rather than instantly withdrawable money. That is the fail-closed direction and it is deliberate, but it is a new hard dependency for anyone running a trimmed edition.

The default weight profile is seeded, not migrated. An environment that runs migrations without running the seeds has no default profile, and every gift or rain grant is refused until one exists. This follows the existing pattern for IAM roles and player tags, and it fails closed, but it is a deployment step rather than something the schema guarantees.

A gift without a provider reference has no idempotency guard beyond the caller's transaction, since its sourceRef is a freshly minted ledger row id. Callers that pass a stable reference - a chat message id, a rain draw id - get the grant's unique index. The model this replaces was equally unguarded.

Stale notification rows. wallet.bonus_rollover.completed rows already in the notification table are dropped from list reads but still counted by the unread badge. Not backfilled, on the same "nothing in production" basis as the table drop.

The gifting player is not on the audit record. The grant is audited as system, and neither the grant port nor the wallet transaction carries the sender. The model this replaces had the same gap; closing it needs a field on the port.

The default grant terms - one turnover, thirty days - are constants in the bonus module for now. They become offer configuration when the offer table lands, which is the next PR in this stack.