feat: add reentrancy guard to release, refund, and cancel_invoice

[Keengfk]

feat: reentrancy guard for release, refund, and cancel_invoice

Summary

Token transfer callbacks in Soroban can re-enter the contract if the token
contract is malicious or misconfigured. This PR protects all fund-moving entry
points with a reentrancy lock backed by temporary storage.

Changes

error.rs

• Added ReentrantCall = 33 to ContractError. Discriminant is append-only
  (stable).

lib.rs

• Added reentrancy_lock_key() — returns a Symbol ("re_lock") used as the
  temporary storage key for the lock.
• Added with_reentrancy_guard() — a closure-based helper that sets the flag on
  entry, runs the body, and clears it on exit.
• Wrapped release_invoice, refund, and cancel_invoice with an inline guard:
  1. If re_lock is present in temporary storage → panic! with ReentrantCall
     error code.
  2. Set re_lock in temporary storage.
  3. Execute the function body.
  4. Remove re_lock on normal exit.

Why temporary storage

Temporary storage is scoped to a single transaction and is automatically
discarded on abort. This means:

• A stale lock can never block a future independent call across transaction
  boundaries.
• No migration or cleanup logic is needed.
• If the function panics (transaction aborts), the lock is dropped with the
  transaction state.

Acceptance criteria coverage

┌───────────┬────────┐
│ Criterion │ Status │
├──────────────────────────────────────────────────────┼────────┤
│ Nested calls to release_invoice return ReentrantCall │
└────────────────────────
closes #479

[drips-wave]

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