Log an error when multiple files resolve to the same namespace

[egrishina]

Problem

DiscoveringFileSystemTranslationSource discovers files named <Namespace>.<discriminator>.<locale>.i18n.json, but FileSystemTranslationSourceBase's filename regex discards the middle segment(s). So Foo.A.en-US.i18n.json and Foo.B.en-US.i18n.json both resolve to namespace Foo, locale en-US.

TranslationData.AddOrUpdateNamespace then silently replaces the first with the last-loaded file (last-wins), with no warning and without even retaining the file paths.

Impact

Any consumer that discovers multiple files for one namespace — e.g. a DiscoveringFileSystemTranslationSource with prefix == null, or a caller that registers AddDefaultLocalization() a second time without a prefix — silently serves whichever file loads last. This is invisible whenever the colliding files have identical content, so it only surfaces once they diverge. We hit exactly this in a service that used per-subdivision files (Foo.Maestra.en-US / Foo.Mindbox.en-US): a Maestra-configured service silently served the Mindbox strings.

Change

• TranslationSet now retains its source FilePath.
• AddOrUpdateNamespace logs an error when a different file overwrites an already-loaded namespace for a locale, naming both files and pointing at the likely cause (a missing discovery prefix). Reloading the same file path stays silent.

Chosen LogError over throwing so it is non-breaking for existing consumers while making the misconfiguration immediately diagnosable; a strict/throw opt-in could be a follow-up.

Tests

Added FileSystemTranslationSourceCollisionTests:

• two files colliding on the same namespace+locale → an error is logged;
• a prefix that isolates one file → no error.

Full suite passes (24 tests).