Video Poker: saturate the payout so a big win cannot overflow the bank

[mishamyte]

Closes #239

score += bet * paytable[] was computed entirely in int, so both the payout and the resulting bank total could overflow. At the bet reported in #239 that corrupted the score, and the score <= 0 check immediately below then dropped the player on the "You have run out of money!" screen - a jackpot reported as a bankruptcy. Depending on the bet it could instead wrap positive and silently pay out the wrong amount, with no game-over at all.

The new bank total is now worked out in 64 bits and saturated:

int hand_rank = recognize(poker_player);
if(hand_rank != 9) {
    int64_t total = (int64_t)poker_player->score +
                    (int64_t)poker_player->bet * paytable[hand_rank];
    poker_player->score = total > MAX_BANK ? MAX_BANK : (int)total;
}

This is the only place the score grows (the other three writes are the two = 1000 resets and the pledge, which subtracts), so the bank - and highscore, which just copies it - can no longer overflow.

Why MAX_BANK and not INT_MAX

An earlier draft saturated at INT_MAX. Review caught that this makes a pre-existing overflow newly reachable: with the bank pinned at exactly INT_MAX, hold Up (bet = score/2) then tap Up (the doubling guard passes with equality, bet = INT_MAX-1) then press Right, and the bet += 10 step overflows. Before the fix the bank could never sit at INT_MAX - it wrapped negative instead - so that window was unreachable.

Capping at roughly half of INT_MAX keeps the whole bet domain away from the type limit rather than requiring a per-site overflow guard, and it composes with the existing invariant: clamp_bet() already binds bet to score, so bounding score bounds bet for free. It also avoids editing the betting logic that just shipped in 1.4 (#163). Every arithmetic site was enumerated against the new ceiling; the tightest (bet += 10) peaks at 1,000,000,009, leaving over INT_MAX/2 of slack.

The cap is disclosed in the changelog rather than being silent policy, and it only ever bites on the way up - a capped win can never look like a loss.

Also in this change

• Hoist the doubled recognize() call into hand_rank. It is idempotent (it only rebuilds its own shand scratch buffer from hand), so this is behaviour-preserving, and it saves a full selection sort plus up to seven predicate checks per paying hand.
• fap_version 1.4 -> 1.5 with a CHANGELOG entry covering both failure symptoms and the new ceiling.

Verification

Builds clean under ufbt (API 88.0), ufbt format applied. Reviewed by the code-review, silent-failure and comment agents plus a four-angle simplify pass; the silent-failure pass fuzzed 20,000 modelled sessions across banks from 1 to INT_MAX and saw zero wins ending as game-over, zero negative banks and zero invalid bets.

Two pre-existing issues were found during review and deliberately left out of scope: the draw callback still calls recognize() twice per frame, and playcard() has an out-of-bounds hold[5] stack access.

🤖 Generated with Claude Code