Deposit credited to wrong user due to sender inference fallback

When parsing deposits, the system tries to determine the sender wallet from parsed token program instructions. If that produces unknown, it falls back to using the first signer in the transaction message as the "sender."

In complex transactions (multi-instruction, aggregator involvement, multisig, relayers), the "first signer" may not represent the depositor. This can result in a deposit being credited to the wrong casino account.

Vulnerable scenario:

1. Create a transaction that results in the vault token account's FAIR balance increasing (valid deposit), but with multiple signers/instructions such that the parsed transfer info returns source/authority as a token account or something that hits the fallback logic, and the "first signer" in accountKeys is not the actual depositor.
2. Submit it and observe the credited wallet differs from the actual depositor.

User funds credited to the wrong account, with no recovery path absent manual intervention. Combined with relayer or aggregator usage, this turns an integration corner case into a fund-loss vector.

Remove the "first signer" fallback. Require an authoritative sender derived from the SPL token transfer instruction (source or owner of the source token account). If sender cannot be determined deterministically, reject the deposit credit and surface the deposit for manual review rather than credit it to a guessed account.

Fair Casino: Fixed. Zealynx: Verified.