[Contracts] LendingPool first-depositor share inflation/donation attack: no minimum liquidity lock #1

Telegram (ask questions / claim the issue here first): https://t.me/+DOylgFv1jyJlNzM0

Why this matters

In lending_pool/src/lib.rs, calc_shares_to_mint gives the first depositor a 1:1 allocation against read_pool_balance (the live token balance), and the share price is derived from that balance in get_share_price/calc_assets_to_redeem. A first depositor can mint 1 share, then donate tokens directly to the contract to inflate share price, so a later depositor's amount * total_shares / total_assets_before rounds down to 0 shares (rejected) or far fewer shares than deposited, letting the attacker redeem the victim's principal. No minimum-liquidity burn or virtual-shares offset is present.

Acceptance criteria

• Adopt a mitigation (e.g. burn a fixed MINIMUM_LIQUIDITY of shares on first deposit, or use virtual shares/assets offsets in calc_shares_to_mint and calc_assets_to_redeem)
• calc_shares_to_mint reverts or rounds in the pool's favor so a donation cannot zero out a subsequent depositor's minted shares
• Add a regression test where a first depositor donates tokens directly to the contract and a second honest deposit still mints fair shares and is fully redeemable
• Document the chosen invariant near calc_shares_to_mint

Files to touch

• lending_pool/src/lib.rs

Out of scope

• Redesigning the entire yield/exchange-rate model
• Changes to loan_manager interest accounting