At session close, the pay later receivable lines are reconciled with every unreconciled posted line of the same partners in the PoS journal and PoS invoices, searched with no bound. A customer buying on credit accumulates one open line per order and none of them is ever matched until a settlement comes in, so this set only grows. On a database with 48k open items for a single partner, the close hands `_reconcile_plan` 55k lines over 28k moves; `_sync_dynamic_lines` then evaluates `m.line_ids.tax_ids` on every move of the container, prefetching the 262k lines of those moves. That is about 1 GiB: the worker is killed and the session cannot be closed.

All of this to reconcile nothing most of the time: reconciliation only pairs opposite signs, and a session that merely adds charges brings no credit to allocate. When there is one, the engine consumes the open items oldest first (`date_maturity` or `date`) and stops when the credit is used up, so anything past that point is loaded for nothing.

Look the open items up per partner, account and currency, and only call `_reconcile_plan` when the session's lines or the customer's open credits give something to allocate. Take the open debits in the order the engine consumes them - the PoS lines have no `date_maturity`, so the ordering is done in Python on `date_maturity or date` - and hand over only as many as the credits cover. Both lookups are capped at 2000 lines: a settlement larger than the oldest 2000 open items leaves its remainder as an open credit, allocated by the next close.

The partials created are the same as before, only the size of the batch given to `_reconcile_plan` changes.

opw-6529792