[Quality Management] Harden IdentifyTableIDFromText fuzzy tests

[Ceshark (6CRIPT)]

What & why

The fuzzy IdentifyTableIDFromText tests relied on system table 6, so their name/caption substrings could match other installed tables or translations and fail. They now use two test-owned temporary fixture tables with unique names and locked captions. Product code is unchanged.

Fixes AB#636554

How I validated this

Ran the Filter Helpers suite in a local BC30 container: 85/85 passed, and the IdentifyTableIDFromText_* tests passed 7/7 in both en-US and it-IT.

[alexei-dobriansky]

Good Sense Reviewer - Round 1

Recommendation: Accept

What this PR does

This change replaces environment-dependent fuzzy table lookup inputs with two test-owned temporary tables that have unique names and locked captions. The updated tests isolate fuzzy name and caption matches, verify ambiguous and missing references, and confirm that successful lookup returns the canonical object name.

The test setup follows the production lookup order: exact name, exact caption, fuzzy name, then fuzzy caption. The match-count checks prove each test reaches the intended branch before the result is asserted, so unrelated installed tables are far less likely to change the outcome.

Problem-solution fit

Fit: Strong

The reported failures come from relying on a common system table whose name or caption can overlap with tables from other extensions. Dedicated fixtures with unique, locked text directly remove that dependency without changing product behavior.

Suggestions

None.

Risk assessment and necessity

Risk: The change is limited to the test app and adds only temporary table objects. It does not change public APIs, persisted data, upgrade behavior, or product logic; the main fixture-count assumptions are checked explicitly in each affected test.

Necessity: The change is needed to keep the fuzzy lookup tests stable when other extensions or translations add similar table names or captions. The scope is narrow and preserves coverage for unique, ambiguous, and missing matches.

---

[AI-PR-REVIEW] version=1 promptVersion=4 system=github pr=12072 round=1 by=alexei-dobriansky at=2026-09-29T18:29:38.8983685Z lastSha=0ea51b44c91dfae2b2800e9d16c400bbb126b7d1 reviewKey=a836bff35c98c14196069dc695c09140fd35b8e9693057aab5977db71fc2e4bb suggestions=none

[alexei-dobriansky]

Interesting approach...

[Ceshark (6CRIPT)]

@alexey-dobriansky
Thanks! I tried and discussed couple more approaches:

1. Creating a new overloaded method that could also receive the set of tables that you want to search in, not only the text. This way I could create a fixed set of 2-3 tables only for the test and keep it isolated and 100% deterministic. The prod could still use the same method that only received the text (that called the other one with all the tables). This was super clean, however after discussing this solution with Attila, we agreed that modifying prod code to sort out a poorly designed test, was overextending.

2. Trying a dynamic search in the tables set to find a couple that would make the test not find more than them, so we could choose an ID that would work. Again, overextending and not deterministic.

This approached looked like the most appropriate for this situation. :)