remaining varargs/List overload gaps in the criteria API

#137 added `where(List)` and friends to `CriteriaQuery` in 3.2, and #1075 extended this to `CriteriaUpdate`/`CriteriaDelete` and the join `on()` methods for 4.0, "for consistency with what we already did to CriteriaQuery in 3.2". A sweep of the rest of the criteria API turns up four operations still missing the corresponding counterpart:

1. **`CriteriaBuilder#construct(Class, Selection...)`** — its siblings `tuple()` and `array()` both gained `List>` overloads in 3.2, but `construct()` did not, even though constructor argument lists are just as often assembled dynamically.

2. **`CriteriaBuilder#function(String, Class, Expression...)`** — the canonical dynamic-arity operation (argument count depends on the SQL function, so arguments are typically collected in a loop), with no `List` counterpart.

3. **`Expression#in(Expression...)`** — no list counterpart, while its sibling `in(Object...)` has had `in(Collection)` since 2.0. Two notes:
- the overload must be declared with `List` rather than `Collection`, since `in(Collection>)` clashes with the erasure of the existing `in(Collection)`;
- today `expr.in(listOfExpressions)` statically binds to `in(Collection)`, treating the expressions as *literal values* — surely never what the caller meant. The new overload is more specific, so on recompile such calls re-bind to the intended semantics. Flagging this binding change explicitly since it deserves deliberate sign-off, though it seems strictly an improvement.

4. **`CriteriaBuilder#concat(List>)`** (3.2, #408) — the inverse gap: a `List` form with no varargs counterpart. In 3.2 a varargs form wasn't cleanly expressible (`Expression...` triggers unchecked generic array creation warnings at every call site), but 4.0's non-generic `TextExpression` makes `concat(TextExpression...)` expressible — the same device that gave `and()`/`or()` their varargs forms.

As far as I can tell these are the only remaining varargs/`List` asymmetries in `jakarta.persistence.criteria` (deliberate exclusions like the deprecated `multiselect()`, `Fetch` having no `on()`, and the `coalesce()`/`in()` builder objects aside).

Start by comparing the existing varargs and List overloads in jakarta.persistence.criteria.CriteriaBuilder and Expression, focusing on construct, function, in, and concat. Confirm the intended signatures and the Expression.in binding change; done means the four missing counterparts are consistently specified and covered by the project's relevant API checks.

Written by the indexing model from the issue text.