5.0.0 still reproduces the null parameter type mismatch from #2632 for repeated named parameters

[hgwr]

Environment

• EclipseLink 5.0.0
• PostgreSQL

Problem
#2683 fixed the null-binding case in DatabaseCall, but 5.0.0 still fails when the same named parameter is used multiple times and the first occurrence is in IS NULL.

This query still fails with :value = null:

SELECT s FROM QuerySyntaxEntity s WHERE ((:value IS NULL AND s.intVal1 IS NULL) OR s.intVal1 = :value)

On PostgreSQL this ends with:

ERROR: operator does not exist: bigint = character varying

The opposite order still works:

SELECT s FROM QuerySyntaxEntity s WHERE (s.intVal1 = :value OR (:value IS NULL AND s.intVal1 IS NULL))

What seems to happen
When DatabaseQuery.rowFromArguments() builds the translation row, repeated named parameters collapse to a single DatabaseField by equality.
If the first occurrence came from :value IS NULL, the surviving field keeps Object type information, and the later typed occurrence does not replace it.
Then the null-binding path in DatabaseCall cannot recover the concrete type from the row.

So this looks like the remaining case from #2632, not a problem in the #2683 direction itself.

Reproduction
The existing PostgreSQL test below reproduces it on 5.0.0:

org.eclipse.persistence.jpa.test.query.TestNullParameterTypeInference