fix(order): skip non-positive match candidates

[phroi]

Why

OrderManager.bestMatch counted non-positive-gain partial candidates as rejected, but the same candidate could still become the returned best match when the empty frontier was allowance-rejected. That allowed a match with zero or negative economic gain to be selected.

Changes

• Keep match-search frontier advancement separate from the returned best profitable match.
• Leave no-match diagnostics at bestGain: 0n instead of the sentinel value.
• Add a regression test covering a non-positive candidate after an allowance-rejected empty frontier.
• Align the exhaustive test oracle with the production invariant that non-empty selected matches must have positive gain.

[gemini-code-assist]

Code Review

This pull request refactors the order matching logic in the order manager. It decouples the frontier advancement tracking from the best match tracking by introducing a separate advance state variable, and initializes bestGain to 0n instead of a large negative number. It also ensures that candidates with non-positive gains are rejected early when partial matches exist. A corresponding unit test has been added to verify that non-positive candidates are not selected after rejecting empty allowances.

[phroi]

/gemini review

[gemini-code-assist]

Code Review

This pull request refactors the order matching logic in OrderManager.bestMatch and exhaustiveSequentialBestMatch to ensure non-positive candidates are not selected after rejecting empty allowances. It decouples the search frontier progression (using a new advance state) from the tracking of the best match. A unit test was also added to verify this behavior. The review feedback points out that ckbAllowance and udtAllowance are initialized in the best object but never used, suggesting their removal to simplify the code.

[phroi]

/gemini review

[gemini-code-assist]

Code Review

This pull request refactors the order matching logic in the order manager and its tests. It separates the tracking of the best match from the search frontier advancement, initializes the best gain to 0n, and ensures that candidates with non-positive gains are rejected. A review comment points out a redundant condition in the exhaustive sequential best match logic where checking for positive gain is unnecessary because the best gain is already initialized to 0n.

[phroi]

/gemini review

[gemini-code-assist]

Code Review

This pull request refactors the order matching logic in OrderManager to prevent the selection of candidates with non-positive gains after rejecting empty allowances. It separates the tracking of the optimal match (best) from the frontier exploration state (advance), ensuring that only candidates with positive gains are selected while still allowing the search frontier to advance. Additionally, corresponding unit tests have been added and updated to verify this behavior. There are no review comments to address, and I have no further feedback to provide.

[phroi]

LGTM

Phroi %37