exp/orderbook: reject negative inputs in exp/orderbook/pools.go

[tamirms]

PR Checklist

PR Structure

• This PR has reasonably narrow scope (if not, break it down into smaller PRs).
• This PR avoids mixing refactoring changes with feature changes (split into two PRs
  otherwise).
• This PR's title starts with name of package that is most changed in the PR, ex.
  services/friendbot, or all or doc if the changes are broad or impact many
  packages.

Thoroughness

• This PR adds tests for the most critical parts of the new functionality or fixes.
• I've updated any docs (developer docs, .md
  files, etc... affected by this change). Take a look in the docs folder for a given service,
  like this one.

Release planning

• I've reviewed the changes in this PR and if I consider them worthwhile for being mentioned on release notes then I have updated the relevant CHANGELOG.md within the component folder structure. For example, if I changed horizon, then I updated (services/horizon/CHANGELOG.md. I add a new line item describing the change and reference to this PR. If I don't update a CHANGELOG, I acknowledge this PR's change may not be mentioned in future release notes.
• I've decided if this PR requires a new major/minor version according to
  semver, or if it's mainly a patch change. The PR is targeted at the next
  release branch if it's not a patch change.

What

Negative xdr.Int64 values wrap to large uint64 values when cast, which would distort liquidity pool payout calculations. Add explicit checks to reject negative reserveA, reserveB, and received/disbursed before the uint64 conversion, consistent with the existing feeBips validation.

Why

This is just a defense in depth validation because the function can never be called with negative inputs (pool reserves are always >= 0 ) and path finding will always call the functions with valid inputs.

Known limitations

[N/A]

[Copilot]

Pull request overview

This PR adds defense-in-depth input validation to liquidity pool calculation functions to prevent negative xdr.Int64 values from wrapping to large uint64 values during conversion. While pool reserves and pathfinding calls should never provide negative inputs in practice, this change adds an important safety check to prevent potential issues from int64-to-uint64 conversion wraparound.

Changes:

• Added negative input validation to CalculatePoolPayout and CalculatePoolExpectation functions
• Added comprehensive test coverage for negative input scenarios including edge cases like math.MinInt64

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
exp/orderbook/pools.go	Added negative input validation checks for reserveA, reserveB, received/disbursed parameters in both CalculatePoolPayout and CalculatePoolExpectation functions
exp/orderbook/pools_test.go	Added comprehensive test cases verifying that negative inputs are properly rejected for both pool calculation functions

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.