MS-270/fix(shippingbo): resolve order processing cron failure due to LazyInitializationException on orderLines

The ShippingBO order processing cron was failing for every order with a LazyInitializationException on the orderLines collection, causing 100% of orders to be skipped.

What changed

LazyInitializationException on orderLines The cron was accessing orderLines outside an active persistence context. Fixed by moving to a two-query batch pattern: order IDs are resolved first, then hydrated with an explicit LEFT JOIN FETCH o.orderLines in a second query executed within a @Transactional context.

Cartesian product in the fetch query The original query fetched o.orderLines and joined o.orderStatusHistories in the same JPQL statement, producing a row cross-product for orders with multiple lines and multiple history entries. The two-query split eliminates this: the ID-resolution query joins orderStatusHistories only (no fetch), and the hydration query fetches orderLines only.

Unbounded memory load All matching orders were loaded into memory in a single query. Replaced with a fixed-size batch loop (always re-queries page 0 so that orders committed as sentToShippingbo = true naturally fall out of subsequent pages).

InvalidDataAccessApiUsageException — LocalDateTime rejected for Date-mapped field OrderStatusHistory.createdAt is mapped as java.util.Date on the entity. The threshold was previously converted via ZoneId.systemDefault() (timezone-dependent), then via ZoneOffset.UTC (still an explicit timezone assumption). Both approaches were fragile. The final fix uses Timestamp.valueOf(localDateTime), which copies date-time fields directly with zero timezone involvement.

Related Issues

Closes MS-270