Fix FAT TCS smart signal finding regression

[masarray]

Root cause

ARSAS v1.6.22 can report signal missing for real TCS points when the customer FAT row contains only an exact data-object leaf such as .TCS1Fail / .TCS2Fail while the discovered Siemens 6MD85 model exposes the full IEC 61850 path (for example ADD/GGIO2.TCS1Fail.stVal). The score-based matcher introduced in PR #140 retained canonical LD/LN normalization but had no bounded recovery for a pathless imported object leaf.

This is visible in the CCPP FAT evidence for AA1C1F13R4: exactly the two TCS rows are pathless while adjacent signals retain full ADD/GGIO2 references.

Fix

• add a low-priority exact object-leaf fallback below exact/canonical/container matching
• require exact IEC object-token equality; no fuzzy or Levenshtein similarity
• permit only absent or known safe value-attribute suffixes such as stVal
• preserve existing unique-best safety: the same leaf in two logical nodes remains ambiguous and is never auto-selected
• preserve functional-constraint filtering in the selection/live-binding layers

Regression coverage

• .TCS1Fail and .TCS2Fail resolve uniquely to their full Siemens MMS references
• duplicate TCS1Fail leaves in different logical nodes remain AMBIGUOUS
• near names such as TCS11Fail and TCS1Healthy remain MISSING

Field expectation

This should remove the false FAT scope safety · 2 signal(s) were not found condition for the affected AA1C1F13R4 TCS rows without weakening FAT scope safety for genuinely uncertain mappings. Physical relay validation is still required before calling the field issue closed.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.