Overview Description

Updating a PO catalog still runs the fuzzy search when the normalized message text is an exact match.

For example, changing "Save changes" to "SAVE CHANGES" gives the same fuzzy key after lowercasing and stripping spaces. That key is already in fuzzy_candidates, but Catalog.update() still compares it with every candidate.

With lots of translated messages, small capitalization or surrounding-whitespace edits can spend a lot of time in these repeated comparisons.

Steps to Reproduce

Run this on the current main branch:

from unittest.mock import patch
from babel.messages import catalog

existing = catalog.Catalog(locale="de")
existing.add("Save changes", "Speichern")
existing.add("Cancel", "Abbrechen")
template = catalog.Catalog()
template.add("SAVE CHANGES")

with patch("babel.messages.catalog.get_close_matches",
           wraps=catalog.get_close_matches) as search:
    existing.update(template)

print(existing["SAVE CHANGES"].string)  # Speichern
print(search.call_count)  # 1

Actual Results

The translation is correct, but get_close_matches() still scans the candidate keys even though "save changes" is already an exact normalized key.

Expected Results

Could we check the existing dictionary first and only run get_close_matches() when that exact normalized key is missing? Identical text already gets the highest possible similarity score, so this would pick the same candidate. The normal fuzzy search would still handle actual wording changes.

Reproducibility

Checked on Python 3.14.5 against e2a1791. The example calls the search every time on that version.

Additional Information

This is separate from #1330: it would leave the existing choice between messages with the same normalized key unchanged.