fuzzy_nucleo: Add a tail proximity bonus to fix the double hits not sorted higher bonus.

[feitreim]

Objective

Fixes #55195

The issue is that if a path contains some part of the query multiple times, like x/x.py it may not outrank results like y/x.py (for the query x), despite the fact that it should.

Solution

I added a very small bonus that rewards the proximity of the matches to the tail-end of the path, this is easy because nucleo naturally favors the tail, so the tail most match for a given query atom will be the one that is found. This bonus does need to be small, though not too small, in order to not disrupt any other scoring orders.

The main benefit of this over a different approach like counting occurrences of an atom is speed, this approach is constant time and just overall very low overhead, but performance would be much more of a concern with other approaches.

Testing

All the file finder tests still pass.

Directly showing off the difference on the case from the original issue:

This case shows that it doesn't overpower the other bonuses, like the length bonus.

Self-Review Checklist:

• I've reviewed my own diff for quality, security, and reliability
• Unsafe blocks (if any) have justifying comments
• The content adheres to Zed's UI standards (UX/UI and icon guidelines)
• Tests cover the new/changed behavior
• Performance impact has been considered and is acceptable

---

Release Notes:

• file_finder: Improved search results from fuzzy file search.

[feitreim]

Okay I have realized that this doesn't work for the x/x.py y/x.py case because nucleo handles single character querys differently than everything else... so it does work for real usage, but just not that little test example..