Fix min_per_apply_amount zero-status checks in applyOrder

[Copilot]

Two bugs in applyOrder caused incorrect order zero-status transitions after a transaction, both introduced with the min_per_apply_amount / max_per_apply_amount feature.

Bug 1 — orderRow zeroed against the wrong constraint

orderRow was being set to 'zero' when its post-transaction left fell below applyingOrderRow's min_per_apply_amount. Each order should be evaluated against its own constraint.

// Before — wrong: uses applyingOrderRow's min constraint to zero orderRow
if (orderNewLeft.lt(applyingOrderMinPerApplyAmount ?? 0)) {
    await Order.update({ status: 'zero' }, { where: { id: orderRow.id } });
}

// After — correct: uses orderRow's own min constraint
if (orderRowMinPerApplyAmount !== null && orderNewLeft.lt(orderRowMinPerApplyAmount)) {
    await Order.update({ status: 'zero' }, { where: { id: orderRow.id } });
}

Bug 2 — Pre-transaction left used for applyingOrderRow zero check

applyingOrderLeft (the value before the transaction) was checked against min_per_apply_amount instead of applyOrderNewLeft (the value after). The pre-transaction check is vacuously always false — if applyingOrderLeft were already below the minimum, the applyInvalid gate above would have rejected the request before reaching this point.

// Before — wrong: applyingOrderLeft is the pre-transaction value
if (applyingOrderLeft.lt(applyingOrderMinPerApplyAmount ?? 0)) { ... }

// After — correct: applyOrderNewLeft is the post-transaction value
if (applyingOrderMinPerApplyAmount !== null && applyOrderNewLeft.lt(applyingOrderMinPerApplyAmount)) { ... }

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.