fix: prevent Create Account DoS via transfer-allocate-assign pattern

[onspeedhp]

Summary
This PR addresses a High Severity Denial of Service (DoS) vulnerability (Issue #4) where an attacker could prevent legitimate wallet or authority creation by pre-funding the target PDA address with a minimal amount of lamports.

Vulnerability Details
The previous implementation relied on the System Program's create_account instruction. This instruction fails if the target account address already holds any lamports (e.g., from a stray transfer or a malicious pre-funding attack). This allowed an attacker to permanently block the creation of specific wallets or authorities by sending them 1 lamport.

Implementation Fix
We have replaced the vulnerable create_account calls with a robust Transfer-Allocate-Assign pattern, encapsulating it in a new helper function utils::initialize_pda_account.

The initialization logic now follows these steps:

1. Transfer: Checks the current balance of the PDA. If it's less than the rent-exempt minimum, it transfers only the difference from the payer. If it's already funded (e.g., by an attacker), this step is skipped or adjusted automatically.
2. Allocate: Uses the allocate instruction to set the specific account size.
3. Assign: Uses the assign instruction to transfer ownership of the account to the Program ID.
4. This pattern ensures that account initialization succeeds regardless of the account's prior balance, effectively neutralizing the DoS vector.