Add configurable auto-rebuy preferences per table

[gboigwe]

Summary

Adds a per-table "AUTO-REBUY" settings button letting players configure one of three rules, checked once per genuine transition into the "waiting" phase (the same phase — alongside "settlement" — the contract's own rebuy entrypoint requires):

• Always rebuy to max: tops up to max_buy_in whenever the stack drops below it.
• Rebuy when below N big blinds: tops up to max_buy_in once the stack drops below a configurable big-blind threshold.
• Never auto-rebuy: the default; does nothing.

The decision (decideAutoRebuy in auto-rebuy.ts) respects, in order: the table's max_rebuys limit (read via the existing get_player_buy_in/max_rebuys on-chain fields), the contract's per-rebuy cap (never requesting more than max_buy_in - currentStack, which never exceeds one full max_buy_in), and the player's wallet balance (read via the payment token's standard SEP-41 balance method) before submitting anything on-chain.

Issue

Closes #164

Scope note on "opponent ranges" — n/a here, but a similar honest scoping note applies to big-blind resolution

getTableConfig reads the big blind from the blinds schedule's first level (blinds_schedule.levels[0].big_blind). This is correct for the common fixed-blinds case. An escalating (tournament-style) multi-level schedule's currently active level would need the same level-selection logic the contract applies internally, which isn't replicated here — documented directly in the code (RebuyRelevantTableConfig.bigBlind's doc comment) rather than silently assumed.

Test plan

• npx vitest run — 150 passed, same 4 pre-existing failures as on main (audio-controls.test.tsx, reconnect-state.test.ts — unrelated, unchanged by this work)
• auto-rebuy.test.ts (12 tests): all three modes, respecting max_rebuys (including the 0 = unlimited case), respecting wallet balance (including the exact-match boundary), and not requesting a negative/zero rebuy when already at or above max
• auto-rebuy-store.test.ts (7 tests): round-tripping each mode, per-table and per-address isolation, and graceful fallback to never on corrupted/unrecognized stored data
• auto-rebuy-settings.test.tsx (5 tests): default selection, saving each mode, the threshold input's conditional visibility, and close behavior
• use-auto-rebuy.test.ts (7 tests, mocking onchain.ts as the network boundary): no-op on never, submits the correct rebuy amount, doesn't submit when already at max or when the wallet balance is insufficient, checks exactly once per entry into "waiting" (not on every re-render), re-checks on a fresh transition back into "waiting", and surfaces a network error via lastError instead of throwing
• npx tsc --noEmit — caught and fixed a real type error in my own first draft (a renderHook test's initialProps type was inferred too narrowly for its later rerender call). All remaining errors are pre-existing and unrelated (token-selector.test.tsx, page.tsx tokenChoice typing, Table.tsx replayEntry/setReplayEntry, reconnect-state.ts) — not touched, since this PR doesn't cause them.
• Note: the on-chain read/write functions in onchain.ts (getTableConfig, getPlayerRebuyCount, getTokenBalance, rebuyOnChain) can't be exercised against a live Soroban RPC node in this environment. They're built by closely following the exact simulateTransaction/scValToNative/submitWalletTx patterns already established and tested elsewhere in this codebase (transaction-simulation.ts, onchain.ts's existing joinTableOnChain/playerActionOnChain), matched against the actual contract signatures in contracts/poker-table/src/lib.rs (get_table, get_player_buy_in, rebuy) rather than guessed.

[drips-wave]

@gboigwe Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits