Fix criteria parameter name collisions

[Marukome0743]

Failing Test

Q	A
BC Break	no
Version	3.6.x

Summary

Calling QueryBuilder::addCriteria() more than once with comparisons on the same field generated duplicate parameter names. The resulting DQL referenced one logical parameter while the query had multiple bound Parameter objects, causing Too many parameters at execution time.

Root cause

Each addCriteria() call created a fresh QueryExpressionVisitor. The visitor avoided parameter-name collisions within one Criteria, but could not see parameters already bound to the QueryBuilder.

Fix

Allow QueryExpressionVisitor to delegate parameter binding through an optional callback. QueryBuilder now keeps the existing field-based name when it is free and uses createNamedParameter() only when a previous criteria or user-defined parameter already occupies that name. Standalone visitor behavior remains unchanged.

This differs from the approach in #10475: the visitor does not receive or retain the query builder's existing parameter collection. Parameter ownership and cross-criteria collision handling remain in QueryBuilder, following the design suggested in that review.

Verification

• Added GH8702Test as an executable SQLite regression test
• Added unit coverage for separate criteria, user-defined collisions, and null comparisons
• vendor/bin/phpunit: 3,488 tests, 12,013 assertions
• vendor/bin/phpcs: passed
• vendor/bin/phpstan analyse -c phpstan.neon: passed

Fixes #8702

[greg0ire]

Hi and thanks for your contribution(s)

May I ask why you are using several identities to contribute? This account seems extremely similar to https://github.com/JamBalaya56562

[greg0ire]

Patches should target 3.6.x

[Marukome0743]

Thanks for pointing this out. I’ve rebased the PR onto the latest 3.6.x branch and updated the target branch accordingly.

Regarding your earlier question, I’m sorry, but I don’t know that account or who operates it. This is the account I use for my contributions.

[greg0ire]

I don’t know that account or who operates it

I will gloss over the obvious overall similarities between your accounts and focus on a single one: if you don't know who operates @JamBalaya56562, why is your email address starting the exact same way as theirs?

[Marukome0743]

I genuinely don’t know who operates that account. Regarding the similarity between the email addresses, I can only speculate that we may have chosen similar prefixes because “Jambalaya” has been popular in Japan. As far as I know, it is simply a coincidence, and I don’t have any further information about that account.

[greg0ire]

I can only speculate that we may have chosen similar prefixes because “Jambalaya” has been popular in Japan.

OK, coincidences happen, I suppose. But then why is "jamablaya" followed by "pyoncafe" in both your email addresses?

@JamBalaya56562, maybe you have the answers to these questions?

Also, extra questions for both of you: are you human? If not, who is operating you?

[Marukome0743]

Yes, I’m human.
Robot doesn't use Anime picture in reply comment.

[greg0ire]

Why did you ignore my first question?

OK, coincidences happen, I suppose. But then why is "jamablaya" followed by "pyoncafe" in both your email addresses?

Too embarrassing?

[Marukome0743]

Sorry, I didn’t mean to ignore your question. I genuinely don’t know why the exact combination “jambalaya.pyoncafe” appears in both email addresses, and I don’t want to invent an explanation. I understand why this looks suspicious, but I don’t know who operates that account, so I can’t provide any further information.

[greg0ire]

Do you remember why you picked jambalaya.pyoncafe, when creating your email address?
Also, what drives you to contribute to open source?

[Marukome0743]

I chose the email address based on an anime that was popular at the time.
There is a Japanese anime called Is the Order a Rabbit? (Gochūmon wa Usagi Desu ka?), and the name was inspired by it.

As for my motivation for contributing, we use Doctrine at work and have encountered this issue in practice.
It has caused real problems for us, and we currently use a partial fix that we maintain ourselves.
I opened this PR because I wanted to contribute that work upstream rather than keep the fix only in our local codebase.