fix(escrow): resolve overlapping return statements in invokeRelease (#485)

[alansamdev]

Problem

main @ 50647ca does not compile:

src/escrow/escrow.service.ts(594,5): error TS1135: Argument expression expected.

EscrowService.invokeRelease contained both sides of a bad merge:

• the SorobanClientService.toScVal encodes every bigint argument as i128, even where the documented contract signature calls for u64 #301 version: an unterminated return this.invokeOnLockedEscrow(...) that wraps the issue key in u64(...), and
• the No row locking anywhere in EscrowService — release(), splitRelease(), and releasePartial() all still have the read-then-write TOCTOU race described by #2, not just releasePartial #303 version: a second full return this.invokeOnLockedEscrow(..., manager) that forwards the transaction manager but passes the key as a bare bigint.

Because of this syntax error, nest build fails and nothing on main can be deployed. Release, split release and refund are the platform's core money paths, and they all live in this service.

Why simply picking one side is wrong

• Keeping only the No row locking anywhere in EscrowService — release(), splitRelease(), and releasePartial() all still have the read-then-write TOCTOU race described by #2, not just releasePartial #303 side silently brings back SorobanClientService.toScVal encodes every bigint argument as i128, even where the documented contract signature calls for u64 #301. A bare bigint is encoded as ScVal::I128, but the contract's release(issue_id: u64, recipients) rejects it, so every payout would fail on-chain.
• Keeping only the SorobanClientService.toScVal encodes every bigint argument as i128, even where the documented contract signature calls for u64 #301 side brings back No row locking anywhere in EscrowService — release(), splitRelease(), and releasePartial() all still have the read-then-write TOCTOU race described by #2, not just releasePartial #303. Without manager, a failed invocation writes lastFailure through a second connection, and that write blocks on the row lock the same request already holds.

What changed

1. fix(escrow) in src/escrow/escrow.service.ts: invokeRelease is now a single invokeOnLockedEscrow call that passes u64(this.onChainKeyFor(escrow)) and manager. The SorobanClientService.toScVal encodes every bigint argument as i128, even where the documented contract signature calls for u64 #301 comment is kept.
2. test(escrow) in src/escrow/escrow.service.spec.ts: a new regression test on the splitRelease path checks both halves at once:
   • args[0] is u64(4850n), not a bare bigint;
   • on a Soroban failure, lastFailure (operation splitRelease) is saved through dataSource.manager.save.

Verification

• npx tsc --noEmit: the TS1135 error in escrow.service.ts is gone.
• npx jest src/escrow/escrow.service.spec.ts: 58/59 pass, including the new test and the existing u64(8801n) / manager assertions. The one failure, fund › locks funds… (typeof args[4] expected bigint), is a separate problem in fund that this PR does not touch.

Related: #301, #303
Closes #485
Closes #486
Closes #488
Closes #317

[drips-wave]

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

[vercel]

@alansamdev is attempting to deploy a commit to the chonilius' projects Team on Vercel.

A member of the Team first needs to authorize it.