fix(api): order getOrdersWithRegistrationNumberInDateRange by id ASC (#362)

## Summary

orders_o::getOrdersWithRegistrationNumberInDateRange() selects orders
matching a registration number within a date range without an explicit
ORDER BY clause. MySQL is free to return rows in any order. The endpoint
at routes/orderInvoicesRoute.php then iterates the result and calls
assignToInvoiceCollection() on each row, so the audit-log +
invoice-collection numbering depend on the arbitrary backend row order.

Add a stable `ORDER BY id ASC` to the SELECT and pin the contract with a
new Pest unit test.

## Test plan

- New Pest test `OrdersRegistrationDateRangeQueryTest` asserts the
SELECT still carries `ORDER BY id ASC`.
- Existing tests in the same file still pass unchanged (they don't
assert on ordering).
- Manual php -l on both modified files shows no syntax errors.

## Commits

- bbd50239 fix(api): order getOrdersWithRegistrationNumberInDateRange by
id ASC

Co-authored-by: Worktree Fix Verifier <agent@truckwash.local>

services/nginx/app/tests/Unit/Orders/OrdersRegistrationDateRangeQueryTest.php

@@ -126,3 +126,26 @@ it('returns early when registration number is blank', function (): void {
         }
     }
 });
+
+it('orders registration-matched orders by id ASC so invoice-collection reassignment is deterministic', function (): void {
+    $dbStub = new OrdersRegistrationDateRangeDbStub();
+    $hadDb = array_key_exists('db', $GLOBALS);
+    $previousDb = $hadDb ? $GLOBALS['db'] : null;
+    $GLOBALS['db'] = $dbStub;
+
+    try {
+        (new orders_o())->getOrdersWithRegistrationNumberInDateRange(
+            'EC21235',
+            '2025-03-01 00:00:00',
+            '2025-04-30 23:59:59'
+        );
+
+        expect($dbStub->lastQuery)->toContain('ORDER BY id ASC');
+    } finally {
+        if ($hadDb) {
+            $GLOBALS['db'] = $previousDb;
+        } else {
+            unset($GLOBALS['db']);
+        }
+    }
+});