Reentrancy Guard Modifier for External Contract Calls

[Luluameh]

Background
Soroban contract calls can trigger external token or custom contracts, opening vectors for reentrancy attacks if state is not updated before external calls.
Goal
Implement a reentrancy guard mechanism to prevent nested recursive invocations of critical settlement and withdrawal functions.
Acceptance Criteria

• Define ReentrancyGuard state in transient or instance storage.
• non_reentrant check in settle_session and withdraw_accrued.
• Reverts transaction with Error::ReentrantCall if reentrancy is detected.
  Key Files
  contracts/src/security.rs, contracts/src/lib.rs

[RaymondAbiola]

@RaymondAbiola has applied to work on this issue as part of the Stellar Wave Program's 5th wave.

Hi, I’d like to work on this issue. I have experience with rust, Solidity, frontend, and backend development, and I’m confident I can deliver a clean solution.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @RaymondAbiola to this issue.

[Truphile]

@Truphile has applied to work on this issue as part of the Stellar Wave Program's 5th wave.

Hi LightForgeHub,

I'm deep in our Soroban security layers and ready to lock down our execution state against nested recursive reentrancy vectors.

Allowing external contract calls—like token transfers or custom hooks—to execute before internal state mutations are finalized is a massive liability. It leaves the door wide open for malicious contracts to hijack the execution flow, recursively draining pools before the system can decrement their balances. Having engineered highly secure contract interfaces for alternative credit systems and decentralized networks, I am well-versed in Soroban's specific state mechanics. I know exactly how to leverage transient or instance storage to build an airtight execution perimeter.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Truphile to this issue.