fix: restrict contract initialization to authorized deployer only

[Fidelis900]

Title: fix: restrict contract initialization to authorized deployer only

Body:

Summary

Fixes #28 — Protect Contract Initialization from Front-Running

The initialize function was callable by any address as long as the contract hadn't been initialized yet. An attacker
could monitor the mempool, detect a deployment, and race to call initialize with their own address as admin.

Changes

• lib.rs: Added e.deployer().require_auth() as the first statement in initialize(). This enforces that only the
  deployer's cryptographically signed transaction can succeed — the race is irrelevant because no other address can pass
  the auth check.
• test.rs: Added test_initialize_rejects_non_deployer — registers the contract without mock_all_auths() and
  asserts that an arbitrary attacker address cannot call initialize.

How it prevents the attack

The existing AlreadyInitialized guard only blocks a second call. It offers no protection if the attacker wins the first
call. e.deployer().require_auth() requires the deployer's signature to be present in the transaction, so even a front-
running transaction submitted by another address will be rejected by the Soroban host before any state is written.

Testing

• Existing tests continue to pass (they use mock_all_auths() which covers deployer auth)
• New test explicitly verifies a non-deployer call is rejected

closes #136

[drips-wave]

@Fidelis900 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