Fix duplicate service updates from STM API

[Copilot]

The STM API returns multiple alerts with identical informed_entities (same route/direction/stop), causing the same service update to be displayed 2–3× for a single stop or route.

Root cause

Multiple distinct alert objects in the API response can resolve to the same (targetUUID, language) key. With no deduplication, all copies were cached and returned. Additionally, the same language key could appear in both headerTexts and descriptionTexts, causing it to be processed more than once per alert.

Fix

• StmInfoServiceUpdateProvider: deduplicate the collected service updates by (targetUUID, language) before returning, keeping the first occurrence
• Distinct languages: the per-alert language set is now built with .toSet() so a language appearing in both header and description texts is only processed once
• parseServiceUpdates extracted: the alert-processing logic is moved into a dedicated internal fun parseServiceUpdates(etatServiceResponse, headerTimestamp, maxValidity, sourceLabel) method, making it independently testable

Testing

Added StmInfoServiceUpdateProviderTest with unit tests covering:

• Duplicate alerts for the same route are deduplicated to one service update per language
• A language present in both header and description texts is not processed twice
• A null API response returns an empty list
• Multiple distinct alerts for different routes each produce their own service updates

Original prompt

---

This section details on the original issue you should resolve

<issue_title>New stm.info API service updates > duplicates</issue_title>
<issue_description>org.mtransit.android.commons.provider.ca.info.stm.StmInfoServiceUpdateProvider

Same service updates appear multiple times.

</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes New stm.info API service updates > duplicates #95

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[mmathieum]

The real & primary issue was using a different agency source ID for creating and deleting the service updates (since the new provider is re-using some code from the old one)

[mmathieum]

/gemini review

[gemini-code-assist]

Code Review

This pull request effectively resolves the issue of duplicate service updates by introducing a deduplication mechanism. The core of the fix, which involves implementing equals() and hashCode() for ServiceUpdate and then using a Set to store the parsed updates, is sound. I particularly appreciate the refactoring of the parsing logic into the new, testable toServiceUpdates function. The accompanying unit tests are well-written and cover the key scenarios, ensuring the fix is robust. Overall, this is a solid improvement to the codebase.