[6.2] Fix duplicate term indexing collision in com_finder

[SRV-KILLER09]

Pull Request resolves #47447.

• I read the Generative AI policy and my contribution is either not created with the help of AI or is compatible with the policy and GNU/GPL 2 or later.

Summary of Changes

This PR fixes duplicate-term indexing collisions in com_finder when different spellings normalize to the same token (example: "Resumé" and "Resume").

Changes included:

• Refactored the term insertion flow to query-builder style.
• Insert now excludes already existing terms before insert (instead of attempting to insert duplicates).
• Added a regression system test covering normalized duplicate terms.

Testing Instructions

1. Enable multilingual sample data (or ensure a multilingual setup is available).
2. Create two published articles with similar normalized terms, for example:
   • Title/content containing Resumé
   • Title/content containing Resume
3. Open Smart Search (Finder) and run indexing.
4. Confirm indexing completes without SQL/indexing errors.
5. Confirm both created articles are present in Smart Search indexed items/results.
6. Run system tests for Finder to confirm regression coverage passes.

Actual result BEFORE applying this Pull Request

In some datasets, Finder indexing could hit duplicate-term insertion collisions when multiple terms normalize to the same value, causing indexing failure/errors.

Expected result AFTER applying this Pull Request

Finder indexing completes successfully even when normalized duplicate terms exist, and all affected articles are indexed correctly.

Link to documentations

Please select:

• Documentation link for guide.joomla.org:

• No documentation changes for guide.joomla.org needed

• Pull Request link for manual.joomla.org:

• No documentation changes for manual.joomla.org needed

[richard67]

Pull Request resolves #47472.

@SRV-KILLER09 Pull requests shall refer to issues, not to other pull requests.

So you should link to issue #47447 .

Or you link to the comment in the other PR, but not using the magic "resolves " keyword, e.g.:

Pull Request for #47472 (comment)

[SRV-KILLER09]

Pull Request resolves #47472.

@SRV-KILLER09 Pull requests shall refer to issues, not to other pull requests.

So you should link to issue #47447 .

Or you link to the comment in the other PR, but not using the magic "resolves " keyword, e.g.:

Pull Request for #47472 (comment)

Hii, I’ve updated the PR description to reference the actual issue (#47447) instead of the old PR.

[richard67]

@SRV-KILLER09 Can the other PR be closed? Looking at the way how it is implemented I would count it as a new feature anway, so it would not go into 5.4-dev but into 6.2-dev, and in 6.2-dev it is done with this PR here. So I think the other one can be closed.

[SRV-KILLER09]

@SRV-KILLER09 Can the other PR be closed? Looking at the way how it is implemented I would count it as a new feature anway, so it would not go into 5.4-dev but into 6.2-dev, and in 6.2-dev it is done with this PR here. So I think the other one can be closed.

I’ve closed the old PR since the updated implementation is now in the 6.2-dev. Thankyou!

[SRV-KILLER09]

I am reworking the failing system test and will push a clean update soon...