Changes

fix(webhook): bound WebhookRetryProcessor memory with batches, skip paused endpoints (#538)

* fix(webhook): bound WebhookRetryProcessor memory with batches, skip paused endpoints

Fixes bxservice/idempiere-rest#537

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

* test(webhook): cover getPendingRetries batching and paused-endpoint exclusion

Refs bxservice/idempiere-rest#537

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

* fix(webhook): enforce retry runtime limit per delivery, not per batch

Refs bxservice/idempiere-rest#537

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

* refactor(webhook): use Query.iterate() for pending retries instead of keyset batches

Refs bxservice/idempiere-rest#537

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

* perf(webhook): stream pending retries to avoid N+1 row loads

Query.iterate() loads IDs up front and re-fetches each row with a separate
SELECT, which means one query per delivery on a backlog of millions.
Switch to Query.stream() so each delivery is built straight off the open
result set, and re-run the query per batch of COMMIT_INTERVAL so commits
never happen while the cursor is open. Processed rows leave the WHERE
clause, so each fresh batch continues where the previous one stopped.

Refs #537

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

* fix(webhook): cap pending-retry query with SQL LIMIT per batch

Query.stream() sets no fetch size, so pgJDBC buffers the whole result set
before the first row is read; stopping after COMMIT_INTERVAL rows in Java
still loaded the entire backlog. Pass the batch size into
streamPendingRetries and apply it via setPageSize, so each query returns
at most one batch. No OFFSET is needed since processed rows leave the
WHERE clause.

Also check the runtime deadline before opening each batch query.

Refs #537

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
 (commit: 19880d6)

fix(expand): normalize detail table name to AD_Table.TableName before model class lookup (#539) (#540)

ExpandParser took the detail table name from the raw $expand text and
passed it to MTable.getClass(), which derives a Java class name from that
exact string and is case-sensitive. The child records themselves load
fine because MTable.get and Query resolve the table case-insensitively.

On a case-insensitive filesystem with exploded-directory bundles (an
Eclipse PDE launch on macOS or Windows), the wrong-case class file is
found on disk and rejected with "NoClassDefFoundError: ... (wrong name:
...)", a LinkageError that escapes catch (Exception ex) and surfaces as
a bare 500. On a case-sensitive filesystem, or from a JAR bundle, the
lookup misses and returns null instead.

Normalize to AD_Table.TableName right after the detail table name is
resolved, matching what #533 did for ModelResourceImpl.

No behaviour change for callers already using the canonical casing.

Fixes #539
Refs #532

Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
 (commit: e513da6)