Lack of reentrancy guard in `cancel_stream` function

[Jaydbrown]

Description

The cancel_stream function currently transfers the remaining token balance back to the sender before fully updating the stream's active state in storage. While Soroban has some mitigations, if the token contract allows for callbacks, this could potentially be exploited to reenter the contract.

Suggested Fix

Apply the Checks-Effects-Interactions pattern strictly:

1. Load the stream state and verify the caller is authorized (Checks).
2. Update the stream state in storage to Canceled and zero out the pending balances (Effects).
3. Perform the token transfers to the sender and recipient (Interactions).
   Optionally, add a standard reentrancy guard if complex callbacks are expected.

[apatafamilycompound123-ops]

Hi, I'd like to work on this issue. I've gone through the description and acceptance criteria and I'm confident I can deliver it. I'll make sure every acceptance criterion is met and submit a clean, tested PR. Please assign it to me.

[grantfox-oss]

🦊 GrantFox — @apatafamilycompound123-ops has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #72)
2. Your PR will be reviewed by the conduit-protocol maintainers

Good luck! Track your progress on GrantFox.

[Jaydbrown]

Just checking in—how is this coming along? Let me know if you need any clarification or help moving this forward!

[grantfox-oss]

🦊 GrantFox — @apatafamilycompound123-ops has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #72)
2. Your PR will be reviewed by the conduit-protocol maintainers

Good luck! Track your progress on GrantFox.